FastJson拒绝服务漏洞分析

前言

从@badcode师傅那里知道了这个漏洞,尝试着分析复现一下,影响范围<=FastJson 1.2.59。

感谢@pyn3rd师傅对OOM机制的讲解。

该漏洞会导致java进程的占用内存迅速涨到JVM允许的最大值(-Xmx参数,默认为1/4物理内存大小),并且CPU飙升。

该漏洞并不能直接打挂java进程,但是可能由于java进程占用内存过大,导致被系统的OOM Killer杀掉以及CPU占用率过高,导致其他响应慢或无响应。

补丁

github上的diff:

scanString针对JSON中\x字符的处理,加入了判断后两个字符是否为hex字符,不为hex字符,直接退出。

还有isEOF方法也进行了逻辑完善。

测试代码

简化了一下,原版的可以看引用里的链接:

import com.alibaba.fastjson.JSON;

import com.alibaba.fastjson.JSONException;

public class fastjsonDos {

    public static void main(String[] args){

        //{"a":"\x

        //是由于fastjson处理字符串中\x这种HEX字符表示形式出现的问题。

        String DEATH_STRING = "{\"a\":\"\\x";//输入字符串长度为8

        try{

            object obj = JSON.parse(DEATH_STRING);

            System.out.println(obj);

        }catch (JSONException ex){

            System.out.println(ex);

        }

    }

}

使用FastJson 1.2.59+jdk8u20,测试机内存20GB。

整体流程分析

根据补丁可以看出,是对JSONLexerbase类中ScanString方法的switch中的case 'x'分支进行了修改,所以在1.2.59的该部分进行下断点。

跟入next方法,到了JSONScanner类的next方法:

可以看到逻辑,会对bp进行+1操作并赋给index,如果index>=this.len(JSON的长度)就会返回EOI,否则返回文本内容。

回到scanString函数,经过了两次next,bp已经为9,而输入的字符串长度为8。

继续往下走,跟入putChar函数:

如果sp与sbuf数组长度相等,就扩张sbuf数组长度(默认大小512,每次扩张大小翻倍,所以看起来OOM的位置应该就在这)

回到scanString中,继续往下走,发现回到了scanString的开头,刚才的代码部分都是在一个死循环当中:

由于此时bp已经大于输入的字符串长度,此时next()会返回EOI(0x1A)不等于双引号,并进入到ch==EOI的分支中,跟入isEOF函数:

bp==lench==EOI&&bp+1==len认为是EOF,但此时bp=10 len=8,后面再调用next方法bp只可能更大,永远不满足isEOF的条件,所以上面的putChar(EOI)会无限的执行,sBuf不断扩大,直到OOM。

emm,但是实际测试的时候还是有点差别的。

单线程运行没OOM异常

首次运行代码很快就报了这么一个异常:

NegativeArraySizeException,数组长度为负值异常,并没有OOM。

在idea中下了一个异常断点到NegativeArraySizeException上,断点断在了putChar方法数组空间扩展的位置:

此时sbuf的长度为1073741824(1G的大小),而sbuf.length的类型为int型,int型最大为2147483647。

而1073741824×2= 2147483648,正好大1,所以下溢出了:

此时内存占用3.3GB左右。

1567675894971.png

通过多方查询,java的默认最大允许内存最大物理内存的1/4,我的测试机应该就是5GB左右,此时还没有到OOM的标准,反而由于下溢出先触发了NegativeArraySizeException这个异常。

多线程运行触发OOM

既然单的不行就来个多的,稍微改下代码,改个多线程的:

import com.alibaba.fastjson.JSON;

import com.alibaba.fastjson.JSONException;

public class fastjsonDos1 implements Runnable{

    public static void main(String[] args)  {

        new Thread(new fastjsonDos1()).start();

        new Thread(new fastjsonDos1()).start();

//        new Thread(new fastjsonDos1()).start();

//       new Thread(new fastjsonDos1()).start();

//        new Thread(new fastjsonDos1()).start();

    }

    public void run() {

        String DEATH_STRING = "{\"a\":\"\\x";

        try{

            object obj = JSON.parse(DEATH_STRING);

            System.out.println(obj);

        }catch (JSONException ex){

            System.out.println(ex);

        }

    }

}

我的测试机20GB内存两个线程就OOM异常了了:

可以看到Thread1先OOM,Thread0缺依然是下溢出问题,所以虽然线程OOM了,但java进程并没有挂掉。

写了一个简单的SpringBoot应用做测试,使用burp以10线程进行访问,可以发现虽然一直报OOM异常,但是java进程却没有挂掉,内存最后稳定在4GB多,即使不再触发漏洞,占用内存也不会再减小。

CPU飙升图:

1567679607611.png

有想做实验的朋友可以尝试着将运行java的-Xmx参数改的大大,然后再运行感受一下。(老实人的微笑)

有关OOM

Java的OutOfMemoryError是JVM内部的异常,是一个可捕获异常,并不会直接导致java进程被Kill掉,顶多线程挂掉。

Linux下当应用程序内存超出内存上限时,会触发OOM Killer机制以保持系统空间正常运行,哪个进程被点名Kill是通过linux/mm/oom_kill.c中oom_badness进行算分选择的,并且可以通过设定oom_adj来调节其被Kill的可能性。

所以,java默认最大1/4物理内存占用,还是不太容易造成系统的OOM的(当然你系统里其他的进程是吃内存怪当我没说)。

但是很多关于java OOM异常的解决文章中建议将最大值改为不超过物理内存的80%,此时就有可能造成内存占用过多,导致被系统Kill掉。

版权保护: 本文由admin所发布,转载请保留本文链接: http://www.yemogege.cn/wzaq-stwz/412.html

免责声明:蓝域安全网所发布的一切渗透技术视频文章,逆向脱壳病毒分析教程,以及相关实用源码仅限用于学习和研究目的
请勿用于商业用途。如有侵权、不妥之处,请联系站长并出示版权证明以便删除! 

侵权删帖/违法举报/投稿等事物联系邮箱:yemogege@vip.qq.com 网站地图