看快手如何干掉Fastjson

      Fastjson是一个阿里巴巴开发的java高性能JSON库，应用范围非常广，在github上star数已经超过2.2万。从2017年1月份到现在，Fastjson 已出现三次无任何条件限制的远程代码执行（RCE）漏洞，在其中两次版本更新中，Fastjson官方在知情的情况下从未披露其更新涉及到漏洞，导致这些漏洞以0day在野，有的长达一年之久。另外其涉及到远程代码执行漏洞更新已有10多次，小编也做过好几次贡献，业内苦Fastjson 久已。下图是一个四哥给的调侃：

     四哥给的调侃真的只是调侃吗？下面我们来具体看下Fastjson的更新历史：

      画红框框的都修复了无任何限制的RCE漏洞，并且前两次中都没提到一个漏洞字眼，可想而知，根本就没把漏洞当做一回事，更谈不上CVE等漏洞管理跟踪措施。

Fastjson使用非常广泛，在各大互联网公司各大框架中都有涉及。在 2019 年，快手因为 Fastjson 发起两次应急响应，分别是针对Fastjson-1.2.48版本的漏洞应急和Fastjson-1.2.60版本的漏洞应急。

在第一次应急中，由于该漏洞是无任何限制的RCE 0day，我们验证完PoC之后，就推动主站自查，在24小时内完成了升级。漏洞很严重，当时内部有些研发可能感知没那么清楚，为了产生更大的威慑力，我们在某个业务站点getshell，截了几张大大的getshell图丢到大群里，大家的动作立马快速了很多。主站主要靠人找服务就完成了升级，但是其他业务去找到所有存量还是有一定挑战的。下面是我们当时做的一些事情：

1.扫描器构造PoC发动扫描，安全组编写了Fastjson的扫描插件，对公司所有站点发起了扫描，还真发现一个漏洞。

2.利用快手代码搜索平台搜索代码仓库，当时还没有第三方库平台，惭愧。

3.从制品库搜索，解压了所有jar包，搜索相应代码，找出相应责任人。

第二次应急是针对Fastjson-1.2.60版本的，有了第一次的经验，从容了一些，搞定PoC，快速推动业务升级即可。

在2020年5 月末 Fastjson 又出 超级RCE 0day，各个安全团队都是焦头烂额，快手安全组从容了很多，我们只剩下个位数仓库受影响。

在Fastjson -1.2.48和Fastjson -1.2.60版本漏洞的应急中，我们一直在反思，是不是得干掉Fastjson，怎么说服业务干掉Fastjson。对于Fastjson的代码质量，基础架构部有一些研究基础，认为Fastjson代码质量不是很好，这为后续推动Fastjson下线奠定了基础。

于是安全组调研了自身封装的Jackson和gson，形成一个初步结论，具体如下表：

有了前面的替代方案，接下来就是推动替代，说实话这真是一个很艰难的任务，对我们的挑战非常大。

第一要务是管住增量，目前是在第三方库的引入上未做强制卡点，但是对于Fastjson这种高危库，安全组在白盒扫描器中添加了相应规则，发现有新增的Fastjson，及时提醒业务方不允许使用。另外也在Check-style禁用了Fastjson，这样研发在开发的过程中就会感知到引入了高危的组件。

其次是存量Fastjson的替换，和基础架构组对出替代方案，依照业务优先级，优先推动主站等核心业务做替换，这些核心业务本身也很重视安全问题，几方立马就把这个事情推动下去了。这里面的核心挑战就是核心业务核心组件存在Fastjson依赖，第一步得把这里面的依赖给去除，否则其他位置还会间接引入Fastjson依赖。推完核心业务，接着按照类似模式推动对外业务，接着推动对内业务，历时快一年总共推动了不到1000个仓库完成替换。目前已经干掉了95%+Fastjson依赖。

对于快手来说，在安全工程师不会被饿死这件事上，fastjson已经难以做贡献了（小编表示好慌）。

第一次应急的过程中还在愁怎么找全Fastjson，不管是快手代码搜索平台还是制品库，都存在覆盖面不全的问题。后面为了提升应急速度，特别是这种第三方库漏洞的应急速度，从gitlab拉取了所有第三方库，通过和第三方漏洞库比较，形成了 Java 三方依赖安全检测。

第三方库漏洞甚至供应链漏洞已经成为不容忽视的一个漏洞形态，我们接下来也会投入更多力量到第三库漏洞管控上，欢迎大家一起交流进步。