2009: A SMB Odyssey
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)
