有 DCM 木马这种前车之鉴，使用各种镜像站的风险有多大？

[cnt2ex]

根据网上已有的资料，黑暗幽灵(DCM)木马的传播方式之一是通过向正常软件的更新程序里注入代码进行感染传播的。这些软件的更新程序既没有通过安全的通道下载更新程序（使用 http 而不是 https ），并且也没有验证哈希值，或者是公私钥签名。所以中间人很容易通过感染这些程序来感染目标。

以上是背景。

由于网络环境原因，很多东西都使用了镜像站（ dockerhub 、pypi 等等）。假设这些镜像站有由于不可抗力的原因存在被篡改的可能，目前是否有比较方便的方法验证下载到的内容没有经过篡改？

目前已知 apt/yum 的软件包都会通过 gpg 验证，因此使用 apt 、yum 的镜像是安全的。但是 dockerhub 、pypi 似乎都没有公私钥签名，平常使用过程中该注意什么？

[PTLin]

还是挂个代理用官方的吧

[Jirajine]

镜像应该是 trustless 的，不然就是严重的安全问题。
这甚至无关“不可抗力”，任何一个能接触到镜像服务器的人，或者任何能够 compromise 镜像服务器的人，随便给哪个服务或者库植入个后门顷刻间就能拥有一大堆肉鸡。

[Ocean810975]

docker trust verify ？

[moenayuki]

docker 直接用 sha256 做 pull 镜像的 tag ，有修改哈希就对不上

[0o0O0o0O0o]

@Jirajine #2 但是不是可以故意给有很多已知漏洞的旧版本？顺着请求的 IP 打过去…

[taoky]

@0o0O0o0O0o 对于 Debian/Ubuntu 的安全 repo ，在 Release 文件里面可以添加 Valid-Until 字段，比如说 bookworm-security 的 Release:

Date: Wed, 05 Jun 2024 20:30:04 UTC
Valid-Until: Wed, 12 Jun 2024 20:30:04 UTC

如果过期了就会遇到类似 https://unix.stackexchange.com/questions/2544/how-to-work-around-release-file-expired-problem-on-a-local-mirror 的情况。

[1423]

不要使用任何镜像站,包括国外的和 vps 商家的
镜像站可以按 IP 统计下载量, 镜像站可以公开展示某个 IP 下载了什么包, 使用 http 的镜像站甚至会让运营商知道你下载了什么包
镜像站更新不及时会阻碍安全更新及时传递, 镜像站有能力 do evil, 所以不要用任何镜像站

[namonai]

@1423 为什么大家不用官方发布的包、而是用镜像站，是不想吗？

[0o0O0o0O0o]

@taoky #6 学到了

[taoky]

@1423

> 镜像站可以公开展示某个 IP 下载了什么包

对，例如 <https://mirrors.tuna.tsinghua.edu.cn/news/release-logs/>，但是公开的日志不包含完整的 IP 地址。

> 使用 http 的镜像站甚至会让运营商知道你下载了什么包

https://web.archive.org/web/20200615045652/https://whydoesaptnotusehttps.com/

> 镜像站更新不及时会阻碍安全更新及时传递

对，所以发行版都不会建议更换安全更新源。例如 Debian 的安装器即使选择了镜像，安全更新也还是从官方拉取（这也是为什么有很多人说装 Debian 的时候换了源下载还慢得要死的原因）

> 镜像站有能力 do evil

有签名机制的 repo 恐怕 do evil 没有那么容易。没有签名的镜像的话……很可惜，只能要么信任镜像站，要么不从镜像站下载。

[RangerWolf]

@taoky 大佬，膜拜！学到了很多新知识

[Jirajine]

@0o0O0o0O0o 没有必要啊，你都可以向客户端推送任意代码了，整个 xz 那样的后门，直接从下载日志拿到肉鸡 ip 连探针都不用。

@taoky 很多 repo 的签名是基于 web of trust 的，只要 compromise 任意一个 key 就等同 compromise 了全部的验证机制。或者你随便安装哪个软件带签名的 repo 需要信任对应开发者的 key 。也有一些包管理器根本就不支持镜像，使用镜像等于使用第三方 repo,root of trust 也是直接从镜像拉。
更理想的分发方式应该是 content addressed ，如 ipfs 。不过使用 p2p 网络那就不止镜像站了，任何 peer 都可以知道你下载了什么包什么版本，并可以以此进行 exploit 。

[0o0O0o0O0o]

@Jirajine #12 我的意思是故意不同步最新镜像，这样还是保留了一些旧的、经过签名验证的、有已知漏洞的包，不过根据 #6 是有应对措施的

[Jirajine]

@0o0O0o0O0o 如果仓库元数据带签名的话，那是没办法只保留一些有漏洞包的，不过确实可以整个暂停安全补丁仓库的同步。不过 Debian 这种要求安全补丁仓库使用官方源的做法，对几乎不能正常访问互联网的地区用户就很糟糕了。把元数据和实际数据分离，元数据只能从官方服务器获取，实际数据可以从任意渠道 trustless 地获取更合适一点。

[0o0O0o0O0o]

@Jirajine #14 你这种假设似乎很依赖传输中的安全性？但 Debian 的源可以不需要这种保障，我觉得 #6 提到的这种策略很好，紧急情况下也只需要管理员编辑一下该时间

[Jirajine]

@0o0O0o0O0o 只能算是一种 mitigation 吧。https 要比 web of trust 可靠多了。前者需要 compromise debian 的服务器（只有少数核心开发者能访问），后者只要 compromise 任意一个维护者的 gpg key 就能绕过验证，这种模式对社区发展是很不利的。