amazon-redshift-jdbc-driver 2.1.0.7及更低版本中存在潜在的远程命令执行问题。当插件与驱动程序一起使用时，它会根据通过sslhostnameverifier、socketFactory、sslfactory和sslpasswordcallback连接属性提供的Java类名来实例化插件实例。在受影响的版本中，驱动程序不会在实例化之前验证插件类是否实现了预期的接口。这可能导致加载任意Java类，有知识的攻击者可以使用这些类控制JDBCURL来实现远程代码执行。
创建 maven 项目，添加依赖
<!-- https://mvnrepository.com/artifact/com.amazon.redshift/redshift-jdbc42 -->
bean.xml
<beans xmlns="http://www.springframework.org/schema/beans"
编写测试代码
import java.sql.Connection;
这个漏洞跟 PostgresQL JDBC Drive 任意代码执行漏洞(CVE-2022-21724) 很类似，就不做具体分析，仅画出漏洞调用图
漏洞修复
要求获取的类名必须是指定类的子类，否则就抛出异常
按照一个漏洞发现的思路来说，PostgresQL-JDBC 存在代码执行和任意文件写入漏洞，那么对于 Redshift-jdbc 也应该存在着类似的任意文件写入漏洞
import java.sql.Connection;
com.amazon.redshift.Driver#connect
通过getLogger设定日志的相关参数，之后将url保存为String temp然后保存日志文件
com.amazon.redshift.Driver#getLogger
前面通过提取jdbcurl中对应的参数，然后调用RedshiftLogger设置日志的相关参数
com.amazon.redshift.logger.RedshiftLogger#RedshiftLogger
此处的logLevel必须为String ERROR、INFO、FUNCTION、DEBUG、TRACE中任意一个
或者为int 1、2、3、6 中的一个
com.amazon.redshift.logger.LogFileHandler#LogFileHandler
在这个地方会根据 \ 来分割文件名和目录，所以我们为loggerFile赋值时需要注意，同时也因为没有做校验，所以可以实现任意文件写入
然后在com.amazon.redshift.Driver#connect触发了保存操作
往期推荐
原创 | 深度剖析GadgetInspector执行逻辑(上)