Borland StarTeam 作为 Borland 公司 ALM 生命周期管理解决方案的重要组成部分，在软件配置管理领域长期享有良好声誉。然而，近期披露的多项安全漏洞，使得该工具的安全性引发了广泛关注与质疑。

受影响的版本范围涵盖 Borland StarTeam Server 2008 至 10.0.0.57，以及 Borland StarTeam MPX 直至 6.7。漏洞根源在于，StarTeam 服务器在处理客户端发送的特定数组数据时，未能正确计算所需分配的内存大小，从而引发了多个整数溢出漏洞。

漏洞描述

具体而言，在 PROJECT_LOGIN 和 SET_SERVER_ACL 两条命令中，客户端发送的报文包含一个 32 位整数值，用于指示条目数量。服务器接收到该值后，分别乘以 8（或 4，取决于文件名或规范）和 12，并直接使用乘积结果分配内存——问题正出在这里：服务器未考虑 32 位整数溢出限制。一旦乘法结果溢出，分配的内存将远小于实际需求，进而触发堆溢出漏洞。攻击者可利用此堆溢出控制特定寄存器，最终执行恶意代码。当然，前提是攻击者需拥有一个有效账号才能发起攻击。

除了服务器本身，StarTeam MPX 也暴露出多个溢出及拒绝服务（DoS）漏洞，以下逐一进行分析。

A] 剩余数据计算整数溢出

在 STMessageBroker67 和 STMulticastService67 进程中，TmsgBufMsgDeserializeEx 函数负责反序列化入站数据。协议报文由三类数据顺序排列：列表、固定大小 16 字节的数组以及剩余数据。关键问题在于计算剩余数据大小时也出现了整数溢出——如果实际使用的数组数量少于报文中声明的数量，该溢出便会触发。不过，好消息是成功利用此漏洞最多仅能导致服务崩溃，因为攻击者无法用任意数据覆盖服务器内存，因而无法获得代码执行能力。

B] 列表处理堆溢出

此漏洞的影响更为严重。报文中列表的起始位置是一个 32 位值，用于指定所有列表组占用的总字节数，而每个列表项由 16 位大小值及其后相应数量的数据组成。服务器在处理时未检查目标缓冲区的大小——攻击者只需构造一个精心设计的报文，即可利用堆溢出导致服务崩溃，甚至执行任意指令。

C] 无法分配内存导致进程终止

最后一个问题较为直接：在计算需要分配的内存总量时——包括报文大小、列表大小、数组数量乘以 16 以及头部大小——如果其中任何一个计算结果导致无法分配足够内存，服务器进程便会直接终止。这本质上是一种拒绝服务（DoS）攻击方式。

厂商补丁

截至目前，Borland 官方尚未发布针对这些安全漏洞的补丁或升级程序。建议仍在部署 StarTeam 的用户密切关注厂商官方主页（https://www.borland.com/），一旦有更新发布请尽快升级。毕竟在软件配置管理环节，安全漏洞的影响不仅限于工具本身，还可能波及整个开发团队的工作流程与代码资产管理。