go x/exp/cmd/txtar:扩展环境变量并在当前目录之外写入似乎存在风险

wvmv3b1j 于 3个月前发布在 Go

关注(0)|答案(6)|浏览(30)

x/exp/cmd/txtar命令没有限制它可能覆盖的文件的范围，这似乎存在风险(例如，参见 https://snyk.io/research/zip-slip-vulnerability )。此外，环境变量的扩展可能会使攻击者更容易构造恶意文件：

$ go install golang.org/x/exp/cmd/txtar@latest
$ cat hmm.txt
-- $HOME/.ssh/not_authorized_keys --
hmm
$ txtar -x < hmm.txt
$ cat ~/.ssh/not_authorized_keys
hmm

(纯文本给予了一点优势，即它更难隐藏恶意路径，但对于足够大的txtar文件，用户不太可能审查所有文件路径。)
我建议x/exp/cmd/txtar默认只写入当前目录内的文件。如果有任何解析在当前目录之外，txtar应该以错误退出。(我认为不写入任何文件是最安全的，但如果txtar的实现碰巧更容易写入范围内的文件，那么这样做也是可以的。)可以提供一个标志来允许对任意文件路径进行扩展。
我还建议默认情况下不要展开环境变量，而是要求使用该功能时需要一个标志。
/cc @bcmills@rsc@FiloSottile

来源：https://github.com/golang/go/issues/46741

6条答案

按热度按时间

jckbn6z71#

可以提供一个标志，以允许扩展到任意文件路径。或者——甚至更好！——提供一个明确的允许变量列表。

赞(0）回复(0）举报 3个月前

8oomwypt2#

我看到了两个相关的风险：

txtar 可以在当前目录之外写入文件。即使没有变量扩展，这也是一个值得关注的问题，例如，以 / 或 ../ 开头的文件路径。
txtar 的行为可能对环境变量敏感。这使得上述问题的风险更高(例如，容易指向 $HOME 中的文件，而不需要猜测它可能在哪里),但我认为它也有自己的担忧(例如，在一个目录中创建一个名为 $USER 的文件，然后依赖这个文件被后续的 glob 处理，从而暴露出运行 txtar 的用户)。
我认为为安全的环境变量提供灵活的允许列表是可以接受的。我只是不想请求太多的控制参数或者添加太多的复杂性。我只希望当我在不受信任的输入上运行 txtar 时，默认情况下我不需要担心我的 SSH 文件被破坏。：)

赞(0）回复(0）举报 3个月前

xriantvc3#

我只想让默认情况下，当我在不受信任的输入上运行txtar时
要清楚：无论如何，你都应该对不受信任的txtar输入保持警惕。txtar归档可以包括点文件(与变量扩展无关),而且有很多方法可以通过工作目录中的各种点文件注入恶意行为(例如.git/config)。

赞(0）回复(0）举报 3个月前

qgzx9mmu4#

我为这个发送了两个CL: