漏洞成因Flink反

漏洞成因Flink反序列化：我差点被那个“乖巧”的RCE漏洞整崩溃了！

哎哟喂,今天咱们不聊别的，就聊聊我最近被Apache Flink那个反序列化漏洞（CVE-2020-17519）折腾到怀疑人生的经历，说真的，这漏洞的成因，简直比我前女友的心思还难猜——表面上人畜无害，背地里直接给我来个远程代码执行（RCE），差点把生产环境搞成大型翻车现场！

这个漏洞到底咋来的？别急，听我慢慢吐槽

你想想啊,Flink作为一个流处理框架，它得接收各种外部数据对吧？就像我小区门口的快递柜，谁都能往里塞包裹，但问题就出在，这个“快递柜”对取件人的身份验证，居然用的是Java反序列化——也就是把二进制的对象流直接“拆包”成Java对象，压根没仔细检查这包裹里装的是不是炸弹！

具体成因嘛,我给你捋一捋：

组件信任链断裂：Flink的RestHandler在处理HTTP请求时，会把base64编码的Yarn配置参数直接丢给YarnClient去反序列化，嘿，这中间没有任何过滤和类型校验，就跟咱家大门上的锁坏了一样，谁拿张废银行卡都能捅开。
黑名单形同虚设：官方虽然加了个resolveClass的黑名单，但我只能说，那名单还没我购物车里“待删除”的垃圾食品长，攻击者随便找个org.apache.hadoop.yarn下的gadget链，轻轻松松绕过去。
版本升级的代价：最气人的是，我一开始以为升级到1.11.3就稳了，结果发现，这漏洞在低版本里反而因为依赖library不全，攻击难度更高一些——怎么说呢，这感觉就像是你本来穿了个有破洞的裤子，结果缝补的时候，把破洞缝得更大了！

我当时排查的过程，简直就是一场悬疑剧！

那天下午,监控平台突然报警，CPU飙到200%+，我一看日志，好家伙，RPC请求里多了个org.apache.hadoop.fs.FileSystem类的异常——当时我还没反应过来，直到看到java.lang.Runtime出现在类加载器里，我后背“唰”地一下冷汗就下来了。

我赶紧用jmap把堆dump拉下来，用Eclipse MAT一分析——乖乖，里面躺着十几个org.apache.ctf开头的恶意对象，还带着一个exec命令的常量和URLDNS探测的痕迹，那一刻我的表情，就是那种你发现女朋友手机里有个备注叫“大宝”的联系人的表情，懂不？

修复过程，我真的会谢！

官方给出的临时修复方案是设置env.java.opts禁用RestHandler的classloader.parent-first模式，但我试了，没用！因为攻击者还能通过JobGraph上传自定义jar包，最后还是我暴力破解——把org.apache.flink.runtime.webmonitor.handlers.JarUploadHandler给二次开发，加了一层白名单类加载器校验，才彻底堵死。

不过说真的,最根本的修复还是得靠反序列化过滤器的防御，比如用ObjectInputFilter配合SerialKiller库，把允许的类全列出来，其他一律拒绝，但说实话，这玩意儿配置起来，比我妈催婚还磨叽！