Microsoft Ring0 Vulnerability++2006-07-11

Make / View Comments

Just publicly released an advisory affecting the Microsoft Windows kernel: Microsoft SRV.SYS Mailslot Ring0 Memory Corruption Vulnerability. I worked with H D Moore (who you most recently heard of from his Browser Fun blog) in discovering this bug. This is a great example of the benefits of having a custom SMB stack, many thanks to HD for sacrificing his Sunday afternoon with me on this.

The kernel memory corruption is obviously interesting as it allows for ring0 code execution. However, I find the following actual attack vector to be more interesting. According to the Microsoft Developer Network (MSDN) documentation, Mailslot communications are divided into two classes. First-class Mailslots are connection oriented and operate over SMB/TCP. Second-class Mailslots provide connectionless messaging for broadcast messages and operate over SMB/UDP. Second-class Mailslots are limited to 424 bytes per message. First-class Mailslots are officially unsupported in the Windows 2000, XP and 2003 operating systems. This is the key point as it means that any code relying on the implicit message size limitation could be exposing a vulnerability. So add mailslots to your list of interfaces to enumerate and examine when auditing a target. Look for calls to the CreateMailSlot API, example:

    push 0          ; lpSecurityAttributes
    push 0          ; lReadTimeout
    push 0          ; nMaxMessageSize
    push slot_name  ; "\\\\.\\mailslot\\mailslot_name"
    call CreateMailslotA

The nMaxMessageSize argument is key as it specifies the maximum size of a single message that can be written to the Mailslot in bytes, a value of zero allows for any arbitrary size (this is what you want). So the big question is, what else is exposed? I know of at least one 3rd party application, details of which will be released when a patch is available. A combination of Googling and examinaton of a number of targets tells me that Mailslot usage is pretty rare (fortunate or unfortunate depending on your point of view), but I'm curious to see what the masses discover.

Make / View Comments

RECON2006 - PaiMei Release2006-06-16

Make / View Comments

As promised, to those of you at my RECON talk, the initial release of PaiMei is available for download from:

http://www.openrce.org/downloads/details/208/PaiMei

You can download my slides (again apologies for running over time) from my respository:

RECON2006-Amini.zip

The bundled framework documentation is available for viewing online as well at:

/PaiMei/

I'll likely blog a bit more about the tool and RECON in general later in the weekend.

Make / View Comments

ShmooCon 20062006-01-06

Make / View Comments

It took a few days of (interspersed) debugging but I finally got memory breakpoints implemented in the Python Win32 debugging engine I wrote last weekend. It's built on the Python ctypes module, which I'm very fond of. Many thanks to the people I leaned on at various times while pulling my hair out trying to figure out what was wrong (hoglund, spoon, skape, drew ...). I'll make it available at some point, it's currently way too ugly but very functional:

    def attach:
    def bp_del:
    def bp_del_mem:
    def bp_is_ours:
    def bp_is_ours_mem:
    def bp_set:
    def bp_set_mem:
    def cleanup:
    def debug_event_loop:
    def detach:
    def disasm:
    def dump_context:
    def enumerate_threads:
    def exception_handler_breakpoint:
    def exception_handler_guard_page:
    def exception_handler_single_step:
    def func_resolve:
    def get_thread_context:
    def hex_dump:
    def hide_debugger:
    def is_address_on_stack:
    def is_printable_ascii:
    def is_printable_unicode:
    def little_endian:
    def load:
    def process_restore:
    def process_snapshot:
    def read_process_memory:
    def resume_thread:
    def set_callback:
    def set_register:
    def set_thread_context:
    def single_step:
    def smart_dereference:
    def stack_range:
    def suspend_thread:
    def terminate_process:
    def virtual_protect:
    def virtual_query:
    def write_process_memory:
    
It's interesting being able to quickly prototype various debugging based ideas in Python:
    pydbg = pydbg()
    
    pydbg.set_callback(EXCEPTION_BREAKPOINT,       h_bp)
    pydbg.set_callback(EXCEPTION_ACCESS_VIOLATION, h_av)
    
    try:
        pydbg.attach(pid)
    
        recv     = pydbg.func_resolve("ws2_32",  "recv")
        recvfrom = pydbg.func_resolve("ws2_32",  "recvfrom")
    
        pydbg.bp_set(recv)
        pydbg.bp_set(recvfrom)
    
        pydbg.debug_event_loop()
    except pdx, x:
        sys.stderr.write(x.__str__() + "\n")
There is still an oustanding question of how exactly Windows deals with guard pages. I put that question up in the forums so people can respond to it:

http://www.openrce.org/forums/posts/110

Make / View Comments