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.
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.
As promised, to those of you at my RECON talk, the initial release of PaiMei is available for download from:
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 |