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

从CVE-2024-37032看供应链安全：Ollama恶意模型注册表攻击链全景解析

news 2026/4/15 0:33:10

1. 漏洞背景：当Ollama遇上供应链攻击

去年冬天，安全圈被一个编号为CVE-2024-37032的漏洞惊醒。这个藏在Ollama模型管理工具中的路径遍历漏洞，让我想起多年前第一次见到"../"这种简单却致命的攻击手法时的震撼。Ollama作为当下最火的本地大模型运行工具，其设计初衷是让开发者能像管理Docker镜像一样轻松管理AI模型，但正是这种便利性埋下了隐患。

想象一下这样的场景：你正在用Ollama测试最新的Llama3模型，执行了条看似平常的ollama pull attacker/rogue-model命令。几分钟后，服务器上的/etc/passwd文件已经躺在黑客的硬盘里。这不是科幻情节，而是CVE-2024-37032漏洞被利用时的真实写照。攻击者只需要搭建一个恶意模型注册表，利用Ollama对digest字段校验不严的缺陷，就能让服务器乖乖交出任意文件。

这个漏洞的特殊之处在于，它完美诠释了现代软件供应链攻击的典型特征——利用开发工具与外部资源的信任关系。就像我们常说的"毒快递"：你从信任的渠道获取资源，却不知包裹在运输途中已被调包。Ollama默认信任从注册表获取的manifest文件，就像快递站默认信任包裹上的标签，结果攻击者只需伪造标签就能让系统把敏感文件"配送"到错误地址。

2. 攻击链拆解：从诱饵到数据回传

2.1 恶意注册表的搭建艺术

攻击第一步是搭建钓鱼服务器。我实测用Python Flask搭建一个伪注册表只需不到50行代码，关键是要模拟Docker Registry API的响应格式。以下是攻击者服务器的核心逻辑：

@app.route('/v2/<model>/manifests/<tag>') def malicious_manifest(model, tag): return jsonify({ "schemaVersion": 2, "config": { "mediaType": "application/vnd.docker.container.image.v1+json", "digest": "../../../../etc/passwd", # 路径遍历payload "size": 1024 }, "layers": [] })

这个伪注册表会响应特定格式的JSON，其中digest字段被注入了路径遍历字符串。有趣的是，攻击者通常会使用insecure:true参数来规避证书验证，这就像给钓鱼网站挂了个"安全站点"的假牌子。

2.2 清单投毒的技术细节

manifest文件相当于模型的"购物清单"，告诉Ollama需要下载哪些组件。正常情况下的digest应该是这样的：

sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

但攻击者会将其替换为：

../../../../../../etc/shadow

Ollama旧版本处理这个字段时，会直接将其拼接到本地存储路径中。由于Go的filepath.Join()函数会规范化路径，最终会指向系统敏感文件。这就好比快递系统把收货地址"北京市/../机密档案室"解析成了"机密档案室"。

2.3 数据回传的隐蔽通道

读取文件只是开始，攻击者还需要建立数据回传通道。我分析过多个真实案例，发现主要有三种方式：

API推送：利用/api/push将读取的文件内容打包成新模型层推送到攻击者服务器
DNS外带：通过DNS查询将文件内容编码在子域名中
错误信息泄露：精心构造请求使文件内容出现在错误响应中

最讽刺的是，很多企业防火墙会放行DNS流量，使得第二种方式成功率惊人。我曾用Base32编码将/etc/passwd内容拆分到多个DNS查询中，完全不被安全设备察觉。

3. 漏洞根源：信任机制的全面崩塌

3.1 输入验证的致命缺失

问题出在modelpath.go文件的GetBlobsPath函数。原始代码就像个不验货的仓库管理员：

func GetBlobsPath(digest string) string { return filepath.Join(blobsDir, "sha256", digest) }

修复后的版本增加了严格的SHA256格式校验：

var sha256Regex = regexp.MustCompile(`^[a-f0-9]{64}$`) if !sha256Regex.MatchString(digest) { return "", fmt.Errorf("invalid digest format") }

这个修复看似简单，却揭示了安全开发的重要原则：所有外部输入都应视为有毒的。就像你不会直接饮用陌生人递来的矿泉水，程序也不该直接信任外部传入的参数。

3.2 供应链安全的连锁反应

Ollama漏洞暴露了AI工具链的特殊风险。与传统软件不同，大模型用户会频繁从各种来源获取模型：

社区分享的微调版本
第三方优化的量化模型
研究机构发布的新架构

这种开放生态使得恶意模型有了可乘之机。去年我们就检测到某个流行模型网站上存在被植入后门的Stable Diffusion变体，下载量超过5万次。

4. 防御实战：从应急响应到体系化防护

4.1 紧急止血方案

如果暂时无法升级，可以采取这些临时措施：

网络层隔离：

# 使用iptables限制Ollama只允许访问可信注册表 iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -d trusted.registry.com -j ACCEPT iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -j DROP

文件系统防护：

# 将Ollama数据目录设置为不可逃逸的chroot环境 mkdir -p /var/ollama/jail mount --bind /var/ollama/data /var/ollama/jail chroot /var/ollama/jail /usr/bin/ollama

4.2 长期防护体系

构建AI供应链安全需要多层防御：

物料清单（SBOM）：为每个模型生成包含所有依赖项的清单
数字签名：要求模型提供者使用类似Cosign的工具签名
沙箱运行：使用gVisor等容器运行时隔离模型执行环境
行为监控：检测模型运行时的异常文件访问模式

我在实际环境中部署过基于eBPF的模型行为监控系统，可以实时捕获可疑的路径遍历尝试：

SEC("tracepoint/syscalls/sys_enter_openat") int trace_openat(struct trace_event_raw_sys_enter* ctx) { char path[256]; bpf_probe_read_user_str(path, sizeof(path), (char*)ctx->args[1]); if (strstr(path, "../")) { bpf_printk("Suspicious path traversal: %s", path); } return 0; }