Baresip项目中的SRTP重协商内存安全问题分析

问题背景

在Baresip项目中，最近引入的SRTP(Secure Real-time Transport Protocol)重协商功能(PR #2975)被发现存在一个严重的内存安全问题。这个问题在GitHub Actions自动化测试中被捕获，表现为堆内存释放后继续使用的错误(heap-use-after-free)。

问题现象

当测试用例执行SRTP重协商功能时，系统报告了一个内存访问违规错误。具体表现为：在RX线程(接收线程)尝试使用已经被主线程释放的AES加密上下文进行解密操作时，触发了地址消毒器(AddressSanitizer)的堆使用后释放检测。

技术分析

错误调用栈

从错误调用栈可以看出：

1. RX线程正在执行SRTP解密操作(aes_set_iv)
2. 主线程已经释放了相关的加密上下文(mem_deref)
3. 释放的内存区域大小为208字节，其中192字节处被非法访问

根本原因

问题的根本原因在于SRTP重协商机制与接收线程之间的同步问题：

1. 线程安全问题：主线程在进行SRTP重协商时，直接释放了整个媒体加密状态(strm->mes)，而没有考虑接收线程可能正在使用这些资源。

2. 资源管理冲突：重协商过程需要替换发送密钥，但当前实现粗暴地释放了整个加密上下文，影响了接收路径的资源。

3. 生命周期管理：加密上下文(AES)被释放后，接收线程仍然尝试使用它来解密传入的RTP数据包。

解决方案

项目维护者采取了以下措施：

1. 临时解决方案：通过PR #3013暂时禁用相关测试用例，防止CI失败。

2. 长期修复方向：

   • 实现适当的锁机制来保护共享资源
   • 分离发送和接收路径的密钥管理
   • 采用更优雅的方式替换发送密钥而不影响接收路径

经验教训

这个案例展示了实时通信系统中几个关键的设计考量：

1. 线程安全：在多媒体处理系统中，接收线程和主线程的交互必须谨慎设计，特别是涉及资源释放时。

2. 密钥管理：加密密钥的生命周期管理需要特别小心，确保旧密钥在被替换后不再被使用。

3. 测试覆盖：复杂的并发场景需要专门的测试用例来验证，简单的功能测试可能无法发现这类问题。

结论

SRTP重协商是一个复杂的功能，特别是在实时音视频通信系统中。Baresip团队通过这个问题意识到了现有实现的局限性，并正在改进其线程模型和资源管理策略。这个案例也提醒开发者，在实现安全相关功能时，必须特别注意并发场景下的资源管理问题。