Live Data 的问题
live data,名词。1. 被写入用于解释并在被某些不明显的操作(例如查看)触发时接管程序流程的数据。 这种黑客手段的一种用途是破坏安全性。 例如,一些智能终端具有允许将字符串下载到程序键的命令; 这可以用来编写 live data,当列在终端上时,它会用一个破坏安全的 病毒 感染它,该病毒在倒霉的用户下次敲击该键时被触发。 再例如,vi 中有一些著名的错误,允许某些文本在仅仅被查看时就将任意命令发送回机器。 2. 在 C 代码中,包含指向函数 hook(可执行代码)的指针的数据。 3. 由程序动态构建并旨在作为代码执行的对象,例如 trampoline。 --摘自 Jargon file,版本 3.2.0
这个链接看起来很无辜。 它只写着
Crusty the Clown fans should click here!!!
也许我有点天真——或者只是愚蠢。 但我点击了那个该死的链接。 实际传输并没有花费很长时间,pageview (Sun 的 PostScript 查看器) 很快弹出了小丑克鲁斯提(来自《辛普森一家》)的图片。 任何麻烦的第一个迹象是我的磁盘驱动器指示灯亮了。 并且一直亮着。 这几乎从未发生过,尤其是在我没有做任何事情的情况下。 我打开了另一个 xterm。 有些事情真的不对劲;我的 tcsh 配置完全错了……
我的驱动器指示灯熄灭了。 我的主目录不见了。
在我的系统管理员的巧妙操作下,我的主目录恢复了(幸运的是,它在前一天晚上被备份了)。 由于灾难发生在清晨,除了前一天晚上的电子邮件外,没有任何东西丢失。
我真是太幸运了。
所有发生的事情是有人在 PostScript 图像中嵌入了一个命令行。 我正在使用的 PostScript 查看器愉快地执行了该命令,并且我 200 兆字节的文件被简单地擦除了。
随着互联网变得越来越复杂,丰富和复杂的数据解释方案变得越来越普遍。 这些方案中的每一个都是潜在的安全漏洞。 传统的安全机制在处理这些问题时效果不佳。
live data 的广泛使用使得找到有效的解决方案非常困难。 用户正在要求更新、更丰富的互联网服务,站点管理员不能拖延太久添加这些服务。 Web 浏览器和 MIME 电子邮件的广泛部署涉及相当大的安全风险,这些风险会带来许多意想不到的后果。
本文介绍的(真实)噩梦故事就是一个很好的例子。 大多数 PostScript 查看器都有安全模式,可以禁用文件写入和程序启动操作,这些操作是 PostScript 语言的一部分。 然而,我的本地配置没有使用安全模式,我被别人的幽默想法给坑了。 嵌入式 PostScript 的问题是众所周知的。 其他(起初)看起来无害的工具也可能存在潜在的问题。
1987 年臭名昭著的互联网蠕虫利用 finger 守护程序中的一个简单的缓冲区溢出漏洞,破坏了大量计算机的安全性。 从历史上看,许多 C 程序都有类似的缺陷——可能没有 finger 漏洞对安全性的危害那么大,但通常就其本身而言也是灾难性的。
考虑一下当前最先进的 Web 浏览器。 目前市场上绝大多数 Web 浏览器都与 NCSA 的 Mosaic 有着共同的渊源。 鉴于在今天的互联网狂潮和抢猪比赛中将 Web 客户端推向市场的巨大市场压力,似乎不太可能有人花费了极大的精力来确保 Web 浏览器安全地解释 HTML。 缓冲区溢出问题(在锚点中似乎特别容易发生)可能会为不择手段的个人提供一种在目标机器上执行任何任意代码序列的方法。
这个问题只会变得更糟。 Java 语言目前正在互联网世界中爆发式增长,而且似乎很可能 Java 会带来很多惊喜。 即使 Java 旨在提供安全机制来防止滥用,但只需要一个漏洞就会导致重大问题。
live data 的另一个例子(很少有人考虑过)是 Emacs 中的局部变量列表。 这是一个非常方便的功能,因为它允许为 Emacs 编辑器进行每个文件的自定义。 例如,程序员可以将他们的花括号和缩进偏好设置编码到文件中,这样其他编辑该文件的 emacs 用户就可以自动遵循相同的花括号约定。 然而,由于许多局部“变量”通常是 Emacs Lisp 函数,因此仅仅在 Emacs 中查看文件可能存在相当大的风险——与使用不安全的查看器查看 PostScript 文件相关的风险相同。
Emacs 的问题相对容易解决。 如果您将变量 enable-local-variables 设置为 nil,则 Emacs 的此功能将被禁用。
似乎最大的风险与最复杂的服务相关。 MIME 电子邮件提供了一种基于电子邮件内容启动查看器程序的机制。 因此,如果您发送 JPEG 图片,则会启动 JPEG 查看器。 因此,可能会涉及到非常大(且快速扩展)的程序集——太多而无法确保合理的安全性。 一些 MIME 配置甚至允许传输和执行 shell 脚本或 Perl 程序。
任何系统中最便宜、最可靠和最安全的组件是不存在的组件。 是否可以通过避免使用构成威胁的先进工具来解决 live data 问题?
站点管理员禁止使用此类工具可能不切实际。 一方面,它们都非常有用,而且人们必须权衡可能存在的重大安全风险与对组织竞争力的威胁。 此外,除了最严厉的站点管理员之外,不太可能有人能够阻止用户获取他们自己的个人 Web 浏览器或 MIME 电子邮件客户端。 法西斯式的站点管理可能会使情况变得更糟,因为使用被禁止工具的个人显然不会将他们正在做的事情告知站点安全人员。
互联网防火墙正成为一种流行的安全机制。 然而,它们似乎不太可能防止恶意的 live data。 它们可以完全阻止有风险的服务(如电子邮件和 Web),但是如果您完全阻止这些服务,那么连接到互联网就没有多大意义了。 防火墙检查来自网络的所有数据并寻找“危险”活动似乎也不切实际。 一方面,我们没有很好的机制来区分“友好的”live data 和“不友好的”live data——而且最危险的 live data 看起来根本不像 live data。 另一点需要考虑的是,尝试解决这个问题所付出的努力可能会给防火墙带来不可接受的性能负担。
似乎没有任何“银弹”解决方案可以解决这个问题。 然而,可以采取一些相当简单的步骤来提供合理的保护
如果可能,请使用您专门为此目的使用的另一个用户 ID 运行您的 Web 浏览器并执行其他可能存在风险的活动(例如,查看 PostScript 文件,运行您下载的程序)。 这使得对您的个人文件或系统造成重大损害的可能性降低。
经常保存您的“点文件”。 仅允许对这些文件进行只读访问也可能有所帮助。 点文件(例如您的 .profile、.emacs、.exrc 或 .rhosts 文件)是 live data 攻击的常见目标。
可能最好的建议是有点偏执。 如果您收到一个看起来像是 shell 脚本的大型 MIME 附件,请像对待武装炸弹一样对待它。
最好的建议不是避免使用 live data 的工具,而是非常小心地使用它们。 意识到风险可能是最好的防御。 所以玩得开心,并注意安全。
David Bonn 当他不忙于滑雪时,他通常在摆弄 Linux。 当他不忙于做这两件事时,他正忙于担任 Mazama Software Labs 的总裁。 自 David 于 1986 年毕业于华盛顿大学以来,他的大部分计算机时间都花在了网络系统上。