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

wvmv3b1j  于 6个月前  发布在  Go
关注(0)|答案(6)|浏览(42)

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

jckbn6z7

jckbn6z71#

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

8oomwypt

8oomwypt2#

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

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

xriantvc3#

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

qgzx9mmu

qgzx9mmu4#

我为这个发送了两个CL:

  • 只允许在当前目录内提取,并为在当前目录外提取添加一个--unsafe标志
  • 为允许扩展的特定环境变量添加一个--env标志

这些标志目前只影响归档提取,即它们在写入归档时没有效果。
我曾尝试在写入归档时也应用这些标志,但我认为这会增加不必要的复杂性。

3qpi33ja

3qpi33ja5#

https://golang.org/cl/371274提到了这个问题:cmd/txtar: extract only in current dir by default

x8goxv8g

x8goxv8g6#

https://golang.org/cl/371275提到了这个问题:cmd/txtar: add flag for environment variables

相关问题