Message-ID: <200402191405.i1JE5oh08744@netsys.com>
From: alun at texis.com (Alun Jones)
Subject: RE: Multiple WinXP kernel vulns can give user mode programs kernel mode privileges

> -----Original Message-----
> From: first last [mailto:randnut@...mail.com] 
> Sent: Wednesday, February 18, 2004 4:15 PM
> 
> There exist several vulnerabilities in one of Windows XP 
> kernel's native API 
> functions which allow any user with the SeDebugPrivilege privilege to 
> execute arbitrary code in kernel mode, and read from and 
> write to any memory 
> address, including kernel memory.

Umm... yes.  And?

May I quote from the Windows 2000 Server Resource Kit?

"Debug programs 
"(SeDebugPrivilege)
"Allows the user to attach a debugger to any process. This privilege
provides access to sensitive and critical operating system components. 
By default, this privilege is assigned to Administrators."

...

> Impact
> ======
> 
> Any user with the SeDebugPrivilege privilege could execute 
> arbitrary code as 
> the kernel, and read from and write to any address the kernel 
> can. The 
> program can do anything to the computer the kernel can, eg. 
> reprogram any 
> computer hardware, such as the BIOS flash memory or patch the 
> kernel in 
> memory.

Yes, it's pretty well documented that SeDebugPrivilege allows the user who
has it to completely subvert any and all processes.  That's what it's there
for, to allow a privileged debugger the ability to inject code and alter
portions of memory.  There is no definition of SeDebugPrivilege that I can
find that says that such operations are limited to user-mode.

> Since the user needs the SeDebugPrivilege, a privilege 
> normally only given 
> to administrators, to exploit these vulnerabilities, these 
> are not serious 
> vulnerabilities.

These are not vulnerabilities at all.  This is how the SeDebugPrivilege is
supposed to work.  This is why you don't give it away - even to developers.
Note that if there is a vulnerability in SeDebugPrivilege, it is that many
developers assume they need it, and beg their administrators to enable the
privilege for them.  SeDebugPrivilege is only needed for debugging processes
that you do _not_ own, most debugging can occur without it.

> The user is also normally an admin so he or 
> she could 
> easily install a device driver to become part of the kernel 
> instead of 
> exploiting these vulnerabilities.

The user is also capable of injecting code into other processes of any kind,
so could install a device driver whether or not he was an administrator.

> Microsoft says it's OK for user mode programs to write to the 
> kernel so long 
> as you have the SeDebugPrivilege privilege, and will not fix anything.

Since it's working as documented, and as has been documented for several
years, I'm really not surprised.

> Workaround
> ==========
> 
> Go to "Local Security Policy\ Security Settings\ Local 
> Policies\ User Rights 
> Assignments" and remove all users and groups from "Debug 
> Programs" and 
> restart your computer. Note that any malicious program with 
> administrator 
> rights could re-enable the SeDebugPrivilege privilege and 
> wait for the next 
> reboot and then gain kernel access. Thus this isn't a very 
> good workaround 
> if you always log on as the administrator.

How does the saying go?  "Then don't do that".

Any malicious program with administrator rights is already game over.

You haven't discovered anything new or hidden, or even particularly
surprising.  If you are allowed to debug any process, you can inject code
and data wherever you want.

Like physical access, providing administrator access or debug privilege to
an attacker is the same as losing.

Alun.
~~~~
-- 
Texas Imperial Software   | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place   | alun@...is.com.
Cedar Park TX 78613-1419  | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

Powered by blists - more mailing lists