---

---

Analysis of the Security of  Windows NT 1 March 1999 59 I thought I'd share my findings with the net community. Hopefully someone will be able to fill in the gaps so that together we'll get the whole picture of what GetAdmin really does. •   The hole: the system service NtAddAtom does not pay attention where it stores the result it returns. GetAdmin abuses this to set bit 0 of the byte at address NtGlo- balFlag + 2. GetAdmin is traversing the list of exports in NTOSKRNL.EXE until it hits the 'NtGlobalFlag' entry. However, a slightly modified version of the exploit could contain the hard coded address of NtGlobalFlag. This would make any access to NTOSKRNL.EXE unnecessary, but it would make the exploit 'less portable' at the same time. •   By setting this bit, it seems, the check for debug privileges is switched off in NtOpen- Process and NtOpenThread. Thus, everyone is able to open any process currently in the system. When you open a process or a thread in Windows NT, your function call is eventually passed to the kernel services NtOpenProcess or NtOpenThread. These services verify, whether you are entitled to open the corresponding process or thread object. It seems, that the debug privilege enables you to open processes or threads not owned by you. When having a closer look at the kernel services, you notice that the above mentioned flag overrides the debug privilege, i.e. you do not need debug privileges if the above flag is set. Seems to be some kind of global debug privilege. But then again, maybe it's more than that and I just haven't looked closely enough. :) Could anyone from MS elaborate on this, please? •   GetAdmin opens the Winlogon process and adds a suspended thread to it. After that, it does some fiddling with the stack of the newly created thread. Guess it inserts some code and a bogus return address to make calls to GASYS.DLL, which eventu- ally grants the administrator privileges after the thread is resumed. [Opening pro- cesses] is easy to verify with PView. Start PView and double click on the Winlogon process - you won't be shown its memory statistics. Now manually set this flag, e.g. with SoftIce, and re-run PView. Now you'll be able to look at the statistics. That means that PView is able to open the process, doesn't it? Maybe I am missing some- thing here. •   The NT* functions are kernel services. User-land processes are not able to write to kernel memory. So, the problem is that NtAddAtom does not check the arguments it is passed thoroughly enough. Some background: The NT* functions are invoked via INT 2E. EAX contains the service number (for NtAddAtom this is 3) and EDX con- tains a pointer to the stack frame to be used when calling NtAddAtom, i.e. the argu- ments, to be passed to it. NtAddAtom takes two arguments: the string representing the atom and a pointer to the memory location the result, i.e. the atom handle, is to be stored in. NtAddAtom fails to assure that this location lies within the address space of the process. Hence it is possible to have the kernel service write the atom handle anywhere we want, e.g. somewhere near NtGlobalFlag. If other services are equally sloppy, then I am afraid that this has just been the beginning in a series of bugs (the buffer overflows on Unix come to mind). •   The...correct fix is to modify the kernel so that it cannot be tricked into abusing its privileges (SUID PROGRAMS ON UNIX COME TO MIND HERE). Microsoft offers a hotfix for the problem.