作者:fnmsd@360云安全
前言
从@badcode师傅那里知道了这个漏洞,尝试着分析复现一下,影响范围<=fastjson 1.5.9。
感谢@pyn3rd师傅对OOM机制的讲解。
该漏洞会导致java进程的占用内存迅速涨到JVM允许的最大值(-Xmx参数,默认为1/4物理内存大小),并且CPU飙升。
该漏洞并不能直接打挂java进程,但是可能由于java进程占用内存过大,导致被系统的OOM Killer杀掉以及CPU占用率过高,导致其他响应慢或无响应。
补丁
github上的diff:
![5d275e48c47a570b00ceb94851256188.png](https://i-blog.csdnimg.cn/blog_migrate/bd377028878b43491edbb4e9ac30570b.jpeg)
scanString针对JSON中x字符的处理,加入了判断后两个字符是否为hex字符,不为hex字符,直接退出。
![1af4b662565917e776e03100472d87de.png](https://i-blog.csdnimg.cn/blog_migrate/af0bc9de4f8d864f7420c0818950eeb5.jpeg)
还有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.5.9+jdk8u20,测试机内存20GB。
整体流程分析
根据补丁可以看出,是对JSONLexerbase类中ScanString方法的switch中的case 'x'分支进行了修改,所以在1.5.9的该部分进行下断点。
![f72700e851be84ee420be028dda2cc06.png](https://i-blog.csdnimg.cn/blog_migrate/623139beaeef9c944a1ef26c113053a4.jpeg)
跟入next方法,到了JSONScanner类的next方法:
![02a16c940fbd9bbe5ce99a5e6386add8.png](https://i-blog.csdnimg.cn/blog_migrate/e46f385d25238d013df528c3c59df33a.jpeg)
可以看到逻辑,会对bp进行+1操作并赋给index,如果index>=this.len(JSON的长度)就会返回EOI,否则返回文本内容。
![280c8a459bd6e7309ff5a701664adb11.png](https://i-blog.csdnimg.cn/blog_migrate/338b618bf408ad12311ccec993686982.jpeg)
![2231e19c92e3b137997fcd5ad11786a9.png](https://i-blog.csdnimg.cn/blog_migrate/18b69a1e324818026247e10fffa5cc69.jpeg)
回到scanString函数,经过了两次next,bp已经为9,而输入的字符串长度为8。
继续往下走,跟入putChar函数:
![52880aa8d24e54871051b477bedc846a.png](https://i-blog.csdnimg.cn/blog_migrate/7b34afed0e5b9f794f2430704994c687.jpeg)
如果sp与sbuf数组长度相等,就扩张sbuf数组长度(默认大小512,每次扩张大小翻倍,所以看起来OOM的位置应该就在这)
回到scanString中,继续往下走,发现回到了scanString的开头,刚才的代码部分都是在一个死循环当中:
![62ed84f75e761e3a6fd213520c6f6f38.png](https://i-blog.csdnimg.cn/blog_migrate/13e2b38168dee74a3e4f50ddc7c13679.jpeg)
由于此时bp已经大于输入的字符串长度,此时next()会返回EOI(0x1A)不等于双引号,并进入到ch==EOI的分支中,跟入isEOF函数:
![04e4a721a02f7b46e299f6f63c4b9164.png](https://i-blog.csdnimg.cn/blog_migrate/78415652055ebcc25c5a076a5f0b4628.jpeg)
bp==len和ch==EOI&&bp+1==len认为是EOF,但此时bp=10 len=8,后面再调用next方法bp只可能更大,永远不满足isEOF的条件,所以上面的putChar(EOI)会无限的执行,sBuf不断扩大,直到OOM。
emm,但是实际测试的时候还是有点差别的。
单线程运行没OOM异常
首次运行代码很快就报了这么一个异常:
![46e4ffc5129aaf13036d72d1c996c96d.png](https://i-blog.csdnimg.cn/blog_migrate/ab3baff1963c8f59c00dc17d719752c6.jpeg)
NegativeArraySizeException,数组长度为负值异常,并没有OOM。
在idea中下了一个异常断点到NegativeArraySizeException上,断点断在了putChar方法数组空间扩展的位置:
![285a0cf717d17b0d3d3adeaf26789263.png](https://i-blog.csdnimg.cn/blog_migrate/184c5565b4330e5bc8e94171efc2ada8.jpeg)
此时sbuf的长度为1073741824(1G的大小),而sbuf.length的类型为int型,int型最大为2147483647。
而1073741824×2= 2147483648,正好大1,所以下溢出了:
![9f1c2941e04690c3f4dede56448d4e6f.png](https://i-blog.csdnimg.cn/blog_migrate/83fc169fe69f37d7c0358460ecaf60aa.jpeg)
此时内存占用3.3GB左右。
![8a4be320e89c8a7fdba4ffc6e002f2bb.png](https://i-blog.csdnimg.cn/blog_migrate/1c2acc18518b8195475a516feccbb7f2.jpeg)
通过多方查询,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异常了了:
![cca090e50d3e91d80dfb7090cab2eae3.png](https://i-blog.csdnimg.cn/blog_migrate/a33f707fb89a78b2fdc670be565bfa0c.jpeg)
可以看到Thread1先OOM,Thread0缺依然是下溢出问题,所以虽然线程OOM了,但java进程并没有挂掉。
![b752881e945a7905b991536b07c44e40.png](https://i-blog.csdnimg.cn/blog_migrate/96dc2ec18754e430b7eb0dc480f17065.jpeg)
写了一个简单的SpringBoot应用做测试,使用burp以10线程进行访问,可以发现虽然一直报OOM异常,但是java进程却没有挂掉,内存最后稳定在4GB多,即使不再触发漏洞,占用内存也不会再减小。
CPU飙升图:
![4bf8a06856aa9da5bda952ca8c310cf4.png](https://i-blog.csdnimg.cn/blog_migrate/282cb8dc9cc85e6bb611f1248555fe58.jpeg)
有想做实验的朋友可以尝试着将运行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掉。
参考
https://github.com/alibaba/fastjson/commit/995845170527221ca0293cf290e33a7d6cb52bf7#diff-aa8d9d6e56964418428ff59fb887afae
https://github.com/alibaba/fastjson/commit/80b7b1e6d57a722f7cca549540394c3072ad8ecb
https://github.com/Omega-Ariston/fastjson/blob/b44900e5cc2a0212992fd7f8f0b1285ba77bb35d/src/test/java/com/alibaba/json/bvt/issue_2600/Issue2689.java
https://blog.csdn.net/liukuan73/article/details/43238623
本文由作者fnmsd@360云安全投稿,转载请注明来源:https://nosec.org/home/detail/2933.html
白帽汇从事信息安全,专注于安全大数据、企业威胁情报。
公司产品:FOFA-网络空间安全搜索引擎、FOEYE-网络空间检索系统、NOSEC-安全讯息平台。
为您提供:网络空间测绘、企业资产收集、企业威胁情报、应急响应服务。