Re: Remote Windows Kernel Exploitation - Step Into the Ring 0

From: Maxim S. Shatskih (maxim_at_STORAGECRAFT.COM)
Date: 03/11/05

  • Next message: Russ Cooper: "MinorRev: Microsoft Security Bulletin MS05-004 - ASP.NET Path Validation Vulnerability (887219)"
    Date:         Fri, 11 Mar 2005 16:40:39 +0300

    > Does anyone on this list know if all kernel code is excepted from NX
    > restrictions by default ?

    I think that the CPU specs from AMD can help in this.

    For instance, the R/O bit handling for ring 0 code is set in some MSR, with the
    Windows default being - "ignore R/O for ring 0". This means that Windows does
    not support copy-on-write for kernel memory, which is a well-known fact.

    > buffer, or icmp handler should be read-execute only (ie trying to patch it
    > should throw an exception of some kind) ?

    Starting from IIRC XP Gold, the kernel code pages are R/O by default.

    > And if the pages are marked read-only, is it possible to patch the
    > for that ?

    Manual hacking of the PTE from the kernel module code is the usual way to go.
    People use this to hook the syscall handlers in some products. The sequence is:

    - save CR3 to EAX using inline assembler
    - assemble the MDL structure "on the knees" with a single physical address from
    EAX at the tail
    - call MmGetSystemAddressForMdlSafe for it
    - you will have the virtual address for the root page directory

    This needs some another way for PAE and 64bit (where the PTEs and PDEs are
    64bit), but very similar. There are also some subtle issues with SMP and

    > As the NX handling is toggable, it is obvious that some part of the kernel
    > be allowed to change it -- and it sounds reasonable that would mean all
    > code can change it, due to the NT memory model.

    Yes. All kernel code has full control over the CPU MSRs and over the PTE

    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation

    NTBugtraq Editor's Note:
    Most viruses these days use spoofed email addresses. As such, using an Anti-Virus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered.

  • Next message: Russ Cooper: "MinorRev: Microsoft Security Bulletin MS05-004 - ASP.NET Path Validation Vulnerability (887219)"