This Black Tuesday (the 13th, no less), Microsoft released the first security patch of 2009. This patch addresses three vulnerabilities in the SRV.SYS driver of the Microsoft Windows operating system. The SRV.SYS driver implements the Server Service component of the SMB network service, exposed via ports 139 and 445. The first issue addressed in this patch (CVE-2008-4114) has been public since September 14th, 2008 and allows a remote user to crash a Windows-based system by sending a malformed WriteAndX request to a named pipe. This flaw is interesting because it is triggered by memory copy, but instead of an overflow, it is a miscalculation of the source pointer. When the target machine receives this write request, it attempts to read from a memory location that may not exist, causing the entire operating system to crash (and by default, reboot). Normally, Microsoft waits until the next service pack to address bugs that do not result in code execution, so having a fix for this before XP SP4 (assuming there is one) is a nice surprise.
The next two bugs (CVE-2008-4834 and CVE-2008-4835) are a little different. These bugs are triggered when the service attempts to zero out a memory buffer that is smaller than a static value. If the attacker sends a request with certain fields set to values smaller than the static buffer size, the resulting operation overwrites the memory after the buffer with NULL bytes. Since we are dealing with driver code and the first buffer is allocated in a kernel pool, the subsequent overwrite usually corrupts the following pool header with a series of NULL bytes. This is where things start to get interesting. The Microsoft bulletin rates this patch as Critical and these two flaws as Remote Code Execution, but in order to execute code, there needs to be a way to leverage a small NULL byte overwrite of a kernel pool header to somehow gain control of execution. While there has been some work in this area, it has focused on using controllable values to overwrite header entries. As far as I know, there is no easy way to leverage a NULL byte overwrite of a pool header into code execution. For this reason, I would agree that these bugs are Critical in the sense that they should be patched as soon as possible (to prevent an easy DoS if nothing else), but I do not believe they will result in code execution. Of course, I would love to be proven wrong :-)
Successful exploitation of the NULL byte overwrite bugs will result in an exception like the following:
BAD_POOL_HEADER (19)
Arg1: 00000020, a pool block header size is corrupt.
Arg2: e2008540, The pool entry we were looking for within the page.
Arg3: e20089f0, The next pool entry. <-- OVERWRITTEN HEADER
Arg4: 0c96020e, (reserved)
BUGCHECK_STR: 0x19_20
f61bac30 80543e86 00000019 00000020 e2008540 nt!KeBugCheckEx+0x1b
f61bac80 f694fad1 e2008548 00000000 f695d2b9 nt!ExFreePoolWithTag+0x2a0
f61bac8c f695d2b9 00000021 e2008550 821e5bd0 srv!SrvFreePagedPool+0x2a
f61baca0 f695771c 820d1610 e2008550 821f1038 srv!SrvFreeTransaction+0x68
f61bacb4 f6958349 00000000 821f1038 e2008550 srv!SrvDereferenceTransaction+0x6b
f61bacec f695786b 00000000 0000001e 821f1038 srv!SrvCompleteExecuteTransaction+0xd0
f61bad04 f6958115 f694be34 821f1038 821f2058 srv!ExecuteTransaction+0x333
f61bad7c f693f836 821f1040 821f2020 f694fa98 srv!SrvSmbTransaction+0x7ac
f61bad88 f694fa98 00000000 8202e200 00000000 srv!SrvProcessSmb+0xb7
SYMBOL_NAME: srv!SrvFreePagedPool+2a
MODULE_NAME: srv
IMAGE_NAME: srv.sys
kd> dd e2008540 (current entry)
e2008540 0c96020e 7274534c 000004a0 00000000
e2008550 04a0030c 00000000 820d1610 821e5bd0
kd> dd e20089f0 (overwritten entry header)
e20089f0 00000000 00000000 00000000 00000000
e2008a00 00000000 00000000 00000000 82270000
======================
http://www.breakingpointsystems.com/community/blog/2009_microsoft_tuesday_coverage
3077
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
