8.3文件格式漏洞导致web server 源代码泄露 (MS,补丁)

时间:2004-04-10 23:11 来源:网管之家bitsCN.com 字体:[ ] 评论:
涉及程序:
windows
 
描述:
8.3文件格式漏洞导致web server 源代码泄露
 
详细:
在Windows平台上每一个长文件名(DOS 8.3 格式不支持)都有一个短文件名(DOS 8.3 格式能支持)的别名。

比如,文件名"longfilename.txt" 的短文件名别名为"longfi~1.txt", 文件名"name.jumbo" 的短文件名别名为"name~1.jum".

从长文件名到短文件名的转换基本是通过取长文件名(包括文件名的扩展部分)的一部分,整理后取6个字符,再附加"~1" 到其上,然后扩展部分取3个字符就构成了短文件名。如果转换成短文件别名后在同一目录下存在相同的文件名,则文件名附加部分的阿拉伯数字相应地加一,依次类推直到得到不同的文件名。

但是这种标准的方式存在一个问题,就是如果文件名部分只有一至两个字符长,就得使用一个不同的方法来产生文件名。

Web服务器通常是根据文件名的扩展部分使用一个相应的handler来处理源文件,当一个特殊的扩展部分没有相应的handler时,将返回未经处理的源文件。

许多运行在Windows平台上的Web服务器,无法有效地根据8.3格式文件名,正确地识别源文件,进行源文件的处理,于是只好简单地尝试着用开头我们提到的标准的方式进行处理。这将意味着和文件名扩展部分响应的handler将被迫为这个文件提供服务(如果是没有此漏洞的Web服务器就会拒绝使用8.3格式文件名服务)。

这在以下的情况中将会产生一个严重的安全问题:

- 一个scripting的扩展名有4个字符长或更长(像 jhtml/jhtm ,shtml/shtm).

- 某些扩展名没有相应的合适的handler。

- 像hello.jhtml 和 helloworld.shtml这样的除扩展名外,文件名名长于2个字符 , 得到的别名是hello~1.jht 和 hellow~1.sht, 但是有漏洞的web服务器不能根据其别名来识别源文件名,只好尝试着使用标准方法,服务器将首先使用提取出扩展部分("jht" 和 "sht"),然后寻找一个相应的handler,但是没有为"sht" 或 "jht" 定义的handler,而将他们的源文件返回,不去运行它。也就是说脚本源代码将会作为输出返回给客户端,这将存在很大的源代码暴露风险。


风险级别:高
 
解决方案:
临时解决方案:
如果你使用的是 Deerfield WebSite Pro 3.1.11.0, 升级到版本version 3.1.13.0
http://www.deerfield.com/download/website/

解决方案:

1.关闭NTFS 8.3文件格式的支持
NtfsDisable8dot3NameCreation
位置:HKEY_LOCAL_MACHINE\SYSTEM
类型:REG_DWORD
范围:0, 1 (False, True)
默认值:0 (False)
建议值:1 (True)

但是这样的话将会导致16位应用程序的兼容性问题

2. 当根据8.3格式文件名扩展部分选择相应的handler时,可使用和原文件名的扩展部分相应的handler。比如如果一个文件名的扩展部分为.jhtml, 你应该在联系.jht 相应的handler时使用.jhtml相应的handler。
 
顶一下(1) 踩一下(0)
Top_arrow