关于 shellshock 漏洞,我有两件事不明白:
为什么允许向未经验证的连接注入环境变量?那有什么好处?
哪些实际服务提供注入变量的能力?
有任何想法吗?
关于 shellshock 漏洞,我有两件事不明白:
为什么允许向未经验证的连接注入环境变量?那有什么好处?
哪些实际服务提供注入变量的能力?
有任何想法吗?
环境变量是与子进程通信的一种非常常见的方式。您不妨问“为什么允许将参数传递给子进程?” 当然,对于环境变量,需要多加注意,因为某些环境变量(PATH
例如 )会影响某些系统调用的语义。因此,通常的约定是将可以从不受信任的输入设置的环境变量限制为一组已知名称。
例如,CGI 协议——它使用环境变量来传达有关 HTTP 请求的信息——将自身限制为一组环境变量名称,这些名称可以松散地描述为CGI 标准,以及名称以开头的任意环境变量。字符HTTP_
。
虽然 CGI 可能拥有最大的用户输入环境变量清单,但该技术非常普遍。一个成熟的例子是使用TERM
来定义远程终端的终端类型,但还有更多。
环境变量,如命令行参数,需要小心处理,有时还需要设置屏障。该/bin/env
实用程序提供了一种机制来清理赋予可执行文件的环境,例如;如果可执行文件以提升的权限运行时环境不可信且必不可少,这将很有用。
除了特定情况(如PATH
),任何应用程序都不应该依赖于干净的环境变量。在没有首先检查其有效性的情况下根据环境变量的值做某事,与对用户提供的数据的任何其他未经验证的使用一样,都是一个错误。(qv SQL 注入攻击。)这就是我们所拥有的:一个简单明了的错误。这些事情都会发生。我们并不完美。(这个漏洞已经存在了二十多年显然没有任何人注意到这一事实,至少,很有趣。)
1) 该漏洞是一个实现错误。故意不允许从不受信任的来源将指令注入环境变量 - 这就是为什么它是一个错误。
2) 请参阅http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCNyvfmSx8E,了解如何利用漏洞的一个很好的示例。