关于java:网传的Spring大漏洞

6次阅读

共计 1895 个字符，预计需要花费 5 分钟才能阅读完成。

昨天凌晨发了篇对于 Spring 大破绽的推文，白天就有不少小伙伴问文章怎么删了。

次要是因为收到敌人揭示说可能发这个会违规（起因可参考：阿里云因发现 Log4j2 核弹级破绽但未及时上报，被工信部处罚），所以就删除了。

通过一天的工夫，仿佛这个事件变得有点看不懂了。所以上面聊聊这个网传的 Spring 大破绽吧。

这个破绽话题的终点源自 3 月 29 日晚，DD 在群里（点击加群）看到网友分享了几位平安大佬爆料 Java 生态呈现了超级大破绽。

但两位大佬都没有走漏这次破绽更具体的信息。只有网友问了一句：“有 log4j 那么大吗？”。云舒大佬的回复是：“更大”。

之后，又有平安大佬 sunwear（就之前那个因为上海银行工作人员服务态度差，而间接怒取 500 万现金的大佬，具体什么故事如果你不晓得能够百度一下，这里 DD 就不细说了）给了一些更细节的信息：

所以破绽影响范畴，能够放大到应用 Java 9+ 和 Spring 的我的项目上了。

此时就有网友开始联合之前 log4j 破绽的信息开始调侃了：

其实到这里，不少小伙们其实曾经松了一口气了，因为国内大部分中央还是在用 Java 8。这点 DD 深有体会，因为每次公布 Java 新版本资讯的时候，始终都有小伙伴反馈，不会降级，版本任你发，我用 Java 8。

反正也睡不着，DD 想着持续搜搜相干信息吧。而后 DD 发现了 Spring 官网最近有这样一个提交：

从提交信息来看，是解决某个 RCE 破绽问题的。所以，大略很可能就是这个了吧？感兴趣的小伙伴，能够通过上面的链接查看具体信息。

https://github.com/spring-pro…

之后有看到一些业余的网络安全类渠道公布了一下修复办法。但没多久，不少号的内容被谐和了，不分明具体起因是什么。

再之后就是 3 月 30 日白天了，接着各种营销号开始炒作这个问题了，比拟扯淡的有两类：一类是张冠李戴，拿过来的一些破绽说是这次的大破绽，因为题目够唬人，所以很多人关注了，而后也在群里探讨。比方又一些说是 Spring Cloud Gateway 的，其实都是 3 月 1 日就曾经颁布的破绽。也有一些说是最近那两个的，但认真看看，你会发现仿佛搭不上边，而且破绽级别都不高。

还有 一类是钓鱼的，因为号称破绽很大，所以放了一些非正式的修复包，理论是恶意代码，来诱惑大家应用。

所以这里 DD 揭示大家一句，当碰到平安问题的时候，肯定肯定要去看官网信息，而不是轻易搜一篇文章就开干了。包含 DD 这边分享进去的内容，肯定也都会放出官网信息的连贯，供大家去核实与解决。

再回到这次网传的破绽信息，其实从 29 日晚开始，大家就都在关注 Spring 官网的信息。然而白天等到的是这篇博文：

这里指出的 CVE-2022-22963 与网传的破绽信息天壤之别，并且级别也并不像之前大佬称的堪比 log4j 的破绽。

所以，再去追溯了一下之前提到的那个对于 RCE 的 PR。能够看到这里的内容有了一些更新：

有网友问：什么时候 report CVE？

@ledoyen 回复：这个自身并不是一个 CVE。应用此工具解决用户输出数据可能会导致 CVE，但在外部像 CacheResultInterceptor 那样应用它的时候，不会导致 CVE。

@sbrannen 最初也给出了论断：这不是 Spring 外围框架中的 CVE。此更改的目标是告诉以前应用 SerializationUtils 反序列化的人，对来自不可信起源对象进行反序列化时候是危险的。而 Spring 外围框架不应用 SerializationUtils 来反序列化来自不可信起源的对象。如果您认为您发现了平安问题，请通过专门的页面来报告：https://spring.io/security-po…。

所以，这个看似解决网传大破绽的 PR 并不是一回事？回头再去看了一下爆料该破绽的云舒大佬的微博，之前发的那条曾经不存在了。那么这个所谓的大破绽去哪里了呢？DD 也猜不进去了，也不瞎猜了，毕竟安全漏洞是个很庄重的事。

最初，因为这个破绽的问题，群里（点击加群）始终有小伙伴问起，所以，按目前 DD 的意识，给大家总结一些留神点：