jdk9 出现比 log4j 更大的漏洞

啥漏洞能不能说清楚

@yazinnnn 这个时间点说清楚违法

不影响 JDK8 安心了

@0o0O0o0O0o

那能不能提供一个解决办法或者复现办法。。。

非长期支持版，有人在生产用？

这下有理由把那些老古董升个级了

是 JDK9 还是 JDK9+? JDK9 应该没什么人用了。

就问一句 jdk17 受不受影响，不影响就没事！

是这个吗 https://xz.aliyun.com/t/11114

不好意思，订正一下，据说是影响 jdk9 以上

还好 我们 gateway 我已经迁移到 nodejs 了，年初把 authserver 也迁移了，现在我们都是在 node.js 上面运行了！暂时不怕了

希望可以加速淘汰 spring ，这么多动态反射操作，又臭又长的各种配置
一个框架还搞个字符串形式的嵌入 dsl ，当时看到就觉得有病

@zydxn 是 spring mvc 的吧，还好不用

@yazinnnn 都在等一个英雄

啥漏洞啊 好慌啊

Spring Cloud Function SPEL 注入远程命令执行漏洞
排查参考： https://cn-sec.com/archives/853272.html
官方修复： https://github.com/spring-projects/spring-framework/commit/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529

没发现能直接利用的

@312ybj 说的不是 Spring Cloud 的呀

有人复现了 但是打码了

https://mmbiz.qpic.cn/mmbiz_png/sGfPWsuKAfdSdviblWkNAwlHD2UQ3yH0ibwOfu3IFbc83XIschNlkpV3SibxEcznXz19SUO3h09YOJMZbbbfoxz1A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1

影响太小了，现在 80%以上的项目都在 jdk8 上

几天之前就有公开的 poc 了
https://github.com/cckuailong/spring-cloud-function-SpEL-RCE

@kernelpanic 不是同一个东西啊？

@XhstormR02 如果是这个 RCE 的话，感觉是搞了个大新闻。
Spring 的 SerializationUtils 我看只有开启了 @EnbaleCaching 才有可能用到。
大部分项目应该也都不用 Spring 的 cacahe 。

今天出的是 spring RCE ，不是前几天的 Spring cloud function RCE ，楼上几个别搞混了

现在公司百分之 90 之上都是 1.7 和 1.8 吧， 最起码应该是个 11.

@Leviathann 然而真的比其他好用得多，也是一家独大

只要 1.8 没大的安全问题，万事大吉

上来一张微博截图 剩下全靠编

强烈围观一下！

@harwck github 有

@Leviathann
问题是淘汰了 spring 了用啥呢
注解配置也没多少东西，想要配置基本跑不掉反射（除非做 mircronuat 那种 apt 代码生成

@Leviathann 了解的越多越会发出我艹真妙，我怎么想不到的感叹，你这寥寥几句就要淘汰 Spring

Spring Cloud Function 没几个项目用吧？

@jzphx 能展开说一下嘛？

@Leviathann
是个技术都有利弊，不去衡量优缺点，反正就要喷彰显自己的优越感。

@wolfie 能展开说一下嘛？

@kran
要组件互相依赖，还要解藕，要么扫包反射、要么编译期做文章。
所谓的又臭又长的配置，就是默认配置不是自己想要的。

@wolfie 扫包的根本目的是不是自动装配而不是依赖解耦？
为了自动装配各种三方包，涂一层封装，然后外化到配置文件，这真的有很大意义吗？
我对 spring 了解不深，所以对它的流行相当茫然。

quarkus 牵着 micronaut 的小手表示看戏.

@kran 抛开 Java 很多时候过度设计不说。一开始必用 Spring 的原因是依赖注入带来的事务管理器，之后就是 Spring Boot 简化了一堆配置。
现在直接用原生 Servlet 搭个项目是真的要愁死人。

@kran
我的理解 依赖解藕 基于 自动装配（控制反转 + 依赖注入）。

没理解外化到配置文件是什么意思。

这下万年 Java8 的又有不升级的理由了

这个漏洞是说的 SpringBoot 2.6.5 刚刚修复的 “CVE-2022-22950: Spring Expression DoS Vulnerability” 么

这个漏洞应该是类似任意文件写入，据说是老漏洞补丁的绕过

Quarkus:

@Leviathann 你是还在用 struts 么？开开眼吧，还又臭又长，笑死

@cheng6563 原来还有这样的历史，涨知识了，是不是说依赖注入导致事务管理变得复杂了？给我的感觉是现在基于注解的事务管理方式比编程式更加复杂不可控。不是抬杠，“简化”与黑箱伴生而存，可能这是社区思考后决定承受的代价吧。

@wolfie 就是说 spring 选择了以自动装配的方式达成依赖解耦？那确实没啥说的，因为我觉得 springboot 的各种问题缘由就在自动装配。个人更倾向于显式的编程式的配置。
外化到配置是说，用配置代替编程接口，这中间增加的复杂度我个人认为不值得。

凭什么觉得比 log4j 危害更大呢

2010-1622 相关

这下，坚守 jdk8 更有理由了

（绝不是因为懒）

建议客户使用 PHP

说了新版本不稳定不可靠吧（幸灾乐祸），jdk8 可以再用十年。

怎么又是 java 的

@kran 扫包的根本目的，ioc 和 di 怎么不是为了解耦

@kran 并没有，大部分情况下一个注解搞定，单理解手写大部分都需要理解很久

@kran 如果在 a 类用 b 类的非静态方法你要 new 然而用 spring 后不需要 new 交由 speingioc 管理，而且面向接口直接声明接口即可

@kran 外化到配置不理解

还是 jdk8 的多

@Bingchunmoli 你没看明白或者我没说明白，我上面说的自动装配不是类的自动装配（ di ），而是库。另外 ioc 为什么就得扫包？如果必须扫，那其它的 di 框架都是假的，如果不必须，那目的就不完全是 di 。

@kran spring-framework 是不扫包的，但是你要声明每一个你要用的 bean ，SpringBoot 简化配置，通过扫描的方式，省略繁琐的配置。 一个项目你要用的 100 个类，你要配置 100 个甚至更多的 bean 标签，折磨啊

@Bingchunmoli 外化到配置确实不是通用语吧，这么说吧，程序员面向接口 /类 /对象编程，在 spring 里面向配置 /注解编程，虽说过于极端，但也是它很突出的一个现象。用 spring 做项目给我感受最大的是离不开搜索引擎（说我菜我肯定认），因为注解和配置打断了我通过 IDE 调试的过程（还是菜），而不用的时候我都可以通过 IDE 和库文档进行下去，几乎不用去搜索。

@kran DI 肯定是要知道使用的对象和需要注入的对象全类名，构造函数和 setter 方法，如果 IOC 不扫包，这些都是手动配置， 库有自动装配吗。 你是指 SpringBoot 的 starter 吗

@kran
1. 既然对 spring 了解不深，那其实很多道理也没法讲清楚。只能说 spring 做得够早够好，抢占了先机，后来的框架虽然有各种优势但是都做不到颠覆，于是大家就还用 spring
2. 事物控制是可以独立使用的，和依赖注入没关系，各种东西自己 new 自己组装也行。事务切面就不用说了是依赖切面的。编程式的事务 api 貌似也有，但是应用场景太少了
3. 编程组装可以，但是东西多了之后编程组装太墨迹了不是么
4. bean 声明之类的外化配置现在没人用了，现在只是把真正的“配置”外化

@Bingchunmoli 这个我知道，但是拿 guice 来对比呢？

@kran 我可以通过规范了解到 spring 的都是 springl 开头，然后都有代码提示，然后也可以点击跳转对应的 Properties 例如 RocketMQProperties
/**
* The name server for rocketMQ, formats: `host:port;host:port`.
*/
private String nameServer;

/**
* Enum type for accessChannel, values: LOCAL, CLOUD
*/
private String accessChannel;

private Producer producer;
对应名字和注释挺简单的，如果是需要 new 就强耦合了，多数据源多种数据库也会麻烦。
@bean 去注解大部分是为了自定义，SpringBoot 的 starter 默认是可用的(三方做的不一定)，为了项目的需求进行一定的替换定制化，如果该类用户代码写了注入容器，Spring 就会取消自己的装配

@sagaxu 显然不是

@kernelpanic 显然不是这个洞

现在 Spring Boot 也是滚动更新，J9 以上也是滚动更新。凡是滚动更新，不出漏洞才不正常。当然，对于 Spring Boot ，以及所有库，的滚动更新，如果你写好写全了单元测试代码（相比于只编码，工作量最少加两倍），那你只要一直用最新稳定版本就没事了，漏洞顺手就改，连手动测试都不需要。以上仅限于上层应用框架，JKD 这种底层基础设施，能不升级就别升级，尤其是 J9 以后那狗日的不考虑向后兼容性的滚动升级。

@lovelynn 因为这个洞可以导致任意代码执行，并且条件只需要 spring+Java9 及以上

@kran 例如 redis
官方默认是可用，但是用户想用 json 可视化
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(RedisOperations.class)
@EnableConfigurationProperties(RedisProperties.class)
@Import({ LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class })
public class RedisAutoConfiguration {

@Bean
@ConditionalOnMissingBean(name = "redisTemplate")
@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
RedisTemplate<Object, Object> template = new RedisTemplate<>();
template.setConnectionFactory(redisConnectionFactory);
return template;
}

@Bean
@ConditionalOnMissingBean
@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
return new StringRedisTemplate(redisConnectionFactory);
}

}

然后用户配置
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
redisTemplate.setConnectionFactory(redisConnectionFactory);
StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
RedisSerializer<Object> redisSerializer = getRedisSerializer();
redisTemplate.setKeySerializer(stringRedisSerializer);
redisTemplate.setValueSerializer(redisSerializer);
redisTemplate.setHashKeySerializer(stringRedisSerializer);
redisTemplate.setHashValueSerializer(redisSerializer);
redisTemplate.setDefaultSerializer(redisSerializer);
redisTemplate.afterPropertiesSet();
return redisTemplate;
}

@Bean
public RedisSerializer<Object> getRedisSerializer() {
Jackson2JsonRedisSerializer<Object> serializer = new Jackson2JsonRedisSerializer<>(Object.class);
ObjectMapper om = new ObjectMapper();
om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL);
/*
* 支持 JDK8 LocalDateTime
*/
om.registerModule(new Jdk8Module())
.registerModule(new JavaTimeModule())
.registerModule(new ParameterNamesModule());
serializer.setObjectMapper(om);
return serializer;
}
自己的自定义去覆盖。

@kran guice demo 首先来配置依赖关系。我们继承 AbstractModule 类，并重写 configure 方法即可。在 configure 方法中，我们可以调用 AbstractModule 类提供的一些方法来配置依赖关系。最常用的方式就是 bind(接口或父类).to(实现类或子类)的方式来设置依赖关系。
一个项目，几百类，都要一一绑定吗

@kran 用户的需求显然是简单更好，而且 java 语言，性能已经不敏感了->
知乎的评论
a:
我们公司的开发框架就是用的这个，但是做很多变动，比如 inject 注解换成了 javax 的，自动扫描 bean ，不用手动标记 singleton ，还没看懂源码是怎么做到的
b:
建议定制的事别搞，不要去学 spring 的 autoscan ，用原生的就挺好了

@chendy 正解， 有些其他优势是取舍达到的。 其他可能只是填补空缺，有很多三角形理论，只能保证两点，想三点全占不可能

@Bingchunmoli 虽然说我很菜，但是这些基础我还是懂的，但是这个过程主要是靠搜索引擎和一些技术文章慢慢积累总结。可以说当时在用 springboot 时，碰到问题去查搜索引擎是第一反应。这种编码上的割裂感前所未有的强烈，也是我不打算再继续深究这个框架的原因。不讨论了。

@Bingchunmoli 这个回一下，guice 不是只有这一种用法。

android 开发者：他们在讨论啥？

@newmlp 真的么 你自己 debug 了？搞明白了？不需要接受实体对象？

spring 全版本 rce 都不一定有 log4j 的危害大。更何况这么多限制的 RCE 。高危漏洞没错，但别动不动就搞过度沸腾

一个 jdk 的漏洞附了一条微博的链接，总觉得哪里怪怪的

@DrJoseph 不能完全算 jdk 的问题，更多的是 spring 的问题

@lovelynn 感谢指正

@kran 因为三层架构的设计吧。

Web 开发一开始是一个接口 action 直接发起调用数据库返回数据，这样手动开关事务处理一下就行了，问题就是输入输出都是 Http 请求，在后台没法复用。

为了解决代码复用问题，用了分层架构设计，至少用于处理接口的 action 层与处理数据的业务层会分开。
这样又有了新问题，两个都含有开关事务的业务方法相互调用就会出现问题，这时就需要一个事务管理器进行处理。Spring 就是当时最为简练完善的方案了。

当时还有另一个框架，叫做 ejb ，更加烦死个人，Spring 已经是非常轻量。

这次的还没报吧，都没 CVE 号

等保测评不通知就不改。

不影响 JDK8 就安心了

还有没修复的吗? POC 都出来了哦
https://github.com/mcdulltii/SpringShell_0-day

用楼上的示例，Java11 下无法复现。反序列化到 `class.module.classLoader.resources` 这里就是空值了。

@knives tomcat 下部署 war 包。Spring boot 的 jar 包无法用这个利用链

@cmxz 既如此，那我就不急着测试了

目前的感想：叫大家出来，就为了这点事.jpg

@knives 还需要 tomcat 部署

我已经分析完了，这个漏洞危害没那么大 是一个 10 年老漏洞的绕过，目标需要 jdk9 以上版本，项目使用了 spring 框架，且要通过 tomcat 来部署，利用方式是以写日志的形式将恶意代码写进指定路径的指定文件，和 log4j 比差了十万八千里

https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ 外网这篇分析文章写的已经很详细了

@LinShiG0ng 这还不大么？

一个 hotfix: https://github.com/blindpirate/spring-rce-2022-03-hotfix

这个洞还是很局限的 没 log4j 大