> -----Original Message----- > From: first last [mailto:randnut@hotmail.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@texis.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.
