Re: Remote Windows Kernel Exploitation - Step Into the Ring 0
From: Tony Mason (Mason_at_OSR.COM)
Date: 03/10/05
- Previous message: Constantino Tobio: "Default domain permissions on who can join a workstation to the domain"
- Maybe in reply to: Eirik Schwenke: "Re: Remote Windows Kernel Exploitation - Step Into the Ring 0"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 10 Mar 2005 14:47:39 -0500 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Kernel stacks are "no execute" by default on x86 platforms that support
NX and are configured for NX support (AMD-64, em64t running Windows XP
SP2 with NX enabled). Thus, NO kernel code is exempt on such
platforms.
Windows will bugcheck ( ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY - 0xFC)
for an attempt to execute stack-based code in kernel mode. This is not
raised as an exception and thus is not something that can be handled
inside a driver using ordinary means (much like a
PAGE_FAULT_IN_NONPAGED_AREA cannot be trapped either).
For processors that do not have NX support, this protection is not
provided.
Once inside the OS ("kernel mode") you are inside the trusted computing
base and thus can change the processor state - so of course NX can be
disabled. The OS developers can make this more difficult, but
ultimately cannot prevent such things from happening - once you allow
someone to install software in your OS, you have given away the keys to
the kingdom. Of course there are ways of mitigating and even preventing
this. For example, you could construct monitoring logic to detect
changes in critical protections and report when they change, or even
restore them. Microsoft has used this technique for years in ensuring
critical licensing related registry keys are not changed without
permission. Other OS designs may utilize multiple levels of control to
have semi-trusted code. However, partially due to its heritage, Windows
assumes only two privilege levels (recall that Windows NT was targeted
to i860 and MIPS R3000 initially, only adding x86 during the development
cycle.) Of course, x64 architecture only provides 2 levels of
protection in long mode.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
Den 02/17/05 10:00 skrev Marc Maiffret:
Does anyone on this list know if all kernel code is excepted from NX
restrictions by default ? Because surely a utility-function like the
keyboard
buffer, or icmp handler should be read-execute only (ie trying to patch
it
should throw an exception of some kind) ?
And if the pages are marked read-only, is it possible to patch the
error-handler
for that ?
As the NX handling is toggable, it is obvious that some part of the
kernel must
be allowed to change it -- and it sounds reasonable that would mean all
kernel
code can change it, due to the NT memory model.
Does anyone have more information on this ?
-- 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. --
- Previous message: Constantino Tobio: "Default domain permissions on who can join a workstation to the domain"
- Maybe in reply to: Eirik Schwenke: "Re: Remote Windows Kernel Exploitation - Step Into the Ring 0"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|