因为JNDI这个玩意,别说用过,很多人连听都没听说过。这么冷门酸爽的东西,有什么理由把它放在一个日志框架里呢?恐怕只有作者想得通。
数据库驱动
很多人接触JNDI,是从数据库的驱动开始的。当然,随着SpringBoot单体发布模式的流行,现在用这种方式来获取数据库配置的古董公司,是越来越少了。
比如,我们可以在tomcat的server.xml里,配置一个叫做xjjdogDB的资源。
- <Resource name="jdbc/xjjdogDB" auth="Container" type="javax.sql.DataSource"
- maxTotal="100" maxIdle="30" maxWaitMillis="10000"
- username="xjjdog" password="123456" driverClassName="com.mysql.jdbc.Driver"
- url="jdbc:mysql://localhost:3306/xjjdog_db"/>
那么,我们只需要在SpringBoot中配置上JNDI这个名字,它就能加载正确的配置。前提是我们需要把SpringBoot服务打包成WAR包发布。像JBoss这样的宣称企业级服务器的软件,就喜欢这么干。
- spring:
- datasource:
- jndi-name: jdbc/xjjdogDB
从这里,我们可以看出。JNDI到底是个神马玩意呢?你可以认为它是一个配置中心,也可以认为它是一个命名服务。其根本功能,就是让你可以通过一个简短的字符串,就能获取一系列的复杂配置和初始化后的功能。
这样,我们就可以避免将这些配置直接写在项目里。程序启动起来,到底加载的什么东西,要看运行的环境配置的什么东西。
具体实现的话,不就是一个可以根据key获取value的HashMap嘛。
危险由此而来
关键是这个value,它不是String,它是一个Object。要从字符串变身为一个正常的类,还要做到通用,那就不得不依靠反射。
这张图是Oracle官方的一张关于JNDI的介绍。上面的都不是关键,关键的地方在于,JNDI通过SPI机制,可以和LDAP、RMI等各种技术,产生联动。
任何为了追求方便而不遵守常规的便捷通道,都会产生问题。SPI是为数不多的打破Java类加载机制的技术,和Unsafe类一样,强大但并不那么推荐使用。
如上图,就是NamingManager类里面的方法getObjectFactoryFromReference。当它从本地加载相应类的时候,如果加载不到,它干了一件不该干但又不得不干的事情,那就是从网络上的代码里面构造相应的对象!
这下,在炫肌肉的同时,可完犊子了。如上图,我们只需要在8000端口启动一个nginx。或者直接使用python启动一个小小的web服务器。
- python -m http.server 8000
能够发起外网请求的服务器,将会乖乖的自动从我们指定的服务器上捞下非法的class文件进行加载。
制作这些攻击性的playload也非常容易,有marshalsec这样的工具,可以很方便的生成。
根据java的类加载机制,在static代码块里面,就可以干一些实际的代码执行逻辑。我们只需要把编译后的a.class放在该放的地方,JNDI这玩意就能够加载它。
- public class a {
- static {
- try {
- String[] cmd = {"calc.exe"};
- java.lang.Runtime.getRuntime().exec(cmd).waitFor();
- } catch ( Exception e ) {
- e.printStackTrace();
- }
- }
- }
上面的代码将会在你部署的服务器上启动一个calc计算器。当然,它还可以干更多事情。
END
从上面可以看出,Java的反射很强大,但是也很危险。SPI功能继承了这个特性,勇猛的暴露了它的弱点。我觉得功能很好啊,但它为什么要存在于日志框架呢?
这可能是因为卷吧。毕竟一个日志框架,也是要有元宇宙的梦想的!