研究员发布 GitLab RCE PoC，允许认证用户以 git 身份执行命令
- 浏览次数 2034
- 喜欢 0
深度优先（depthfirst）安全研究团队于 7 月 24 日公开了一份可生效的漏洞利用代码，目标是一处 GitLab 漏洞；GitLab 早在六周前的 6 月 10 日就已发布该漏洞补丁。只要未安装更新，任何自托管版 GitLab 18.11.3 服务器均可被该漏洞利用，攻击者将以git 账号权限执行系统命令。
任何拥有项目推送权限的认证用户均可触发该漏洞。攻击者提交一份精心构造的 Jupyter Notebook 文件，并打开该提交的差异对比页面，借此泄露堆指针。收集足够多此类内存地址后，自动化探测程序即可定位内存中的系统库文件。随后再通过两份 Notebook 文件触发最终攻击载荷。
攻击无需管理员权限、无需 CI/Runner 访问权限、无需受害者交互、也无需访问其他用户项目。
GitLab 并未将本次修复标记为安全补丁。《黑客新闻》核查发现：6 月 10 日补丁版本中，Oj 库升级至 3.17.3 的改动被归类在常规程序缺陷修复栏目下，并未列入安全修复清单。该漏洞没有分配 CVE 编号、无 CVSS 风险评分，文档也完全没有提及这套基于 Notebook 差异页面的完整攻击链。运维人员对照安全修复清单评估本次版本更新时，没有理由将其判定为紧急更新。
整套攻击链依托 Ruby JSON 解析库 Oj 中的两处内存损坏漏洞，Oj 主体由原生 C 语言实现。depthfirst 表示，其自动化系统自主识别出这两个漏洞，研究人员人工将二者串联形成完整利用链路。
GitLab 内置的 Notebook 渲染组件是一个名为
ipynbdiff的内置 Gem 程序包；该组件会将仓库内可控的.ipynbJSON 文件传入常驻运行的 Puma 工作进程内的Oj::Parser.usual.parse接口。这意味着由攻击者可控的数据，可以直达应用进程内部、由 Oj 自行管理的 C 语言堆内存区域。第一个漏洞：程序向固定大小 1024 字节的嵌套栈越界写入，最终实现控制解析器的启动回调函数。
第二个漏洞：在有符号 16 位字段中，将长度 65565 字节的对象键截断为 29 字节，并返回一个有效的堆指针；GitLab 会将该指针渲染展示在差异页面中。利用该信息泄露可以定位 libc 库地址；结合越界写入漏洞，就能把回调函数指向
system()系统调用。受影响版本与修复版本
| 组件 | 受影响版本 | 首个修复版本 |
|---|---|---|
| GitLab CE/EE | 15.2.0 ~ 18.10.7 | 18.10.8 |
| GitLab CE/EE | 18.11.0 ~ 18.11.4 | 18.11.5 |
| GitLab CE/EE | 19.0.0 ~ 19.0.1 | 19.0.2 |
| Ruby Oj Gem 库 | 3.13.0 ~ 3.17.1 | 3.17.3 |
社区版（CE）、企业版（EE）所有付费等级（免费版至旗舰版 Ultimate）全部受影响；Ruby 语言本身不存在漏洞。Oj 3.17.2 版本包含同一轮代码审查的其他修复，但并未修复上述两个关键漏洞。
升级建议：升级至 18.10.8、18.11.5 或 19.0.2 版本。
GitLab 与 depthfirst 均无法为无法升级的环境提供缓解方案。depthfirst 研究员吴宇航向《黑客新闻》表示：目前没有公开文档记载可以完全关闭这条存在漏洞的 Notebook 差异渲染路径的 GitLab 配置项；depthfirst 也未验证出一套可靠、可对外推荐的纯配置规避方案。他称，理论上阻止不受信任用户访问 Notebook 差异渲染功能即可消除攻击入口；但无法升级的运维团队应当直接向 GitLab 获取适配自身部署架构的专业指导。
针对 Helm 与 Operator 部署环境重要提醒
务必核查运行 Puma 服务的 Webservice 镜像内的 GitLab 版本，不要只参考 Chart 包或 Operator 组件版本。
版本 15.2 至 18.9 系列不会获得补丁回溯移植，这些版本不在 GitLab 安全维护补丁支持周期内，此类环境必须整体迁移至受支持的正式版本。
漏洞执行命令的身份为运行 Puma 服务的 git 系统账号。所能窃取、操控的资源上限取决于部署环境的隔离程度。潜在目标包括：源代码、Rails 密钥、服务凭证、CI/CD 流水线数据，以及应用程序能够连通的各类内部服务。
公开的漏洞利用代码基于 x86-64 架构的 GitLab 18.11.3 版本开发。代码内的指令小工具偏移、寄存器状态、jemalloc 内存分配器行为均提取自该镜像；同时获取到的库基地址仅在 Puma 主进程重启前有效，因此该 EXP 无法直接照搬用于任意目标。
补充安全说明
Oj 库的两处漏洞属于通用型缺陷，攻击适用范围远不止这一个特定镜像。吴宇航表示，该攻击链路并非仅限 18.11.3 版本；针对同一架构下其他 GitLab 构建版本进行适配，通常仅需小幅调整，主要更新指令小工具或符号偏移地址。相近版本之间这类偏移值往往完全不变 —— 因为指令小工具取自 Ruby 与系统底层库，而非 GitLab 自身业务代码。
架构才是最大适配门槛：移植至 ARM64 架构意味着调用约定、指令小工具、寄存器使用方式全部改变，堆内存行为也可能存在差异；相比 GitLab 版本，Ruby 编译版本、libc 库、内存分配器、编译环境带来的影响更大。
depthfirst 测试统计：全新部署、仅开启两个工作进程的环境中，内存搜索耗时约 5 至 10 分钟；长期持续运行的实例上，耗时可能达到 1 至 2 小时。完整攻击链路分析文档已对外发布。
depthfirst 于 5 月 21 日上报 Oj 库漏洞，库维护者 5 月 27 日合并修复代码，Oj 3.17.3 于 6 月 4 日正式发布。整套 GitLab 攻击链相关信息在 6 月 5 日提交 GitLab 厂商，厂商 6 月 8 日完成漏洞确认，6 月 10 日上线补丁。
吴宇航说明：depthfirst 并未为这两组漏洞申请 CVE 编号。GitLab 相关攻击链通过厂商 HackerOne 漏洞平台提交，平台也未分配独立漏洞编号；两处 Oj 漏洞直接提交给库维护者，团队同样没有申请 CVE，据其所知也没有自动分配编号。他强调，没有 CVE 编号仅代表本次漏洞披露的协调方式，和漏洞严重等级无关。
depthfirst 称暂未监测到野外实际利用行为，同时 GitLab 已独立复现该远程代码执行（RCE）漏洞。吴宇航表示，该结论依据是没有收到相关攻击报告，且团队仅在自有研究环境中复现成功，并非依托遥测数据得出；depthfirst 无法访问 GitLab 内部数据与客户环境，相关大范围态势结论应当以 GitLab 官方信息为准。该团队针对 Oj 库开展大范围代码审查还另外产出 9 条 CVE 公告，但均与本次攻击链无关。
《黑客新闻》曾向 GitLab 提问：为何本次修复未归类为安全问题、后续是否会分配 CVE 编号，GitLab 尚未给出回应。若厂商后续答复，本文将持续更新。