[7637] in bugtraq
Re: [ NT SECURITY ALERT ] New Local GetAdmin Exploit
daemon@ATHENA.MIT.EDU (David LeBlanc)
Wed Aug 12 18:02:39 1998
Date: Wed, 12 Aug 1998 09:38:43 -0400
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
To: BUGTRAQ@NETSPACE.ORG
This appears to have been lost in the mail spool snafu.
>From: dleblanc@mindspring.com
>Date: Wed, 12 Aug 1998 15:33:14 +0000
>At 11:23 PM 7/28/98 -0700, Jonathan H. Pickard wrote:
>
>>First problem: why are we allowed to modify a shared resource
>>(even a local copy of it) even as mortals? WARNING: Don't put
>>business logic in DLL's (and definitely do NOT export your
>>"BOOL bIsALegalTransaction(...)" type functions).
>
>Because the DLL we're playing with has to be loaded into our program space
>in order for us to run it. We have to be able to write the memory to store
>state, etc, just like any other function. Something that should be pointed
>out here is that OpenProcess() is a wrapper around a kernel call named
>ZwOpenProcess(). We can't modify anything in ZwOpenProcess().
note - what most calls look like is that we push an argument into a
register that tells NT what system call to make, then calls an interrupt.
After that, we're in kernel mode. Apparently, the call in question made >
1 system call and stored results in user mode. Whoops.
>Business logic should be kept server-side. Anything else is crazy.
>
>>Second problem: why are we allowed to modify a text segment at all?
>
>Even if that memory page were tagged as read-only, we could still modify
>it. It is in our space. If it has an address of 0x80000000 or less, it is
>our's and we can write it.
>
>>Is it possible to modify .EXE's locally too? (Since a lot of
>>programs use their own DLL's for various things, and several programs
>>(such as the Perl interpreter) keep the entire guts of the program
>>in a DLL, is that .EXE question academic?)
>
>Well, sure - it has long been a way to crack games and such - start the
>game, run a crack that modifies the memory, and now you can rip off the
>game programmers.
>
>>Imagine, if you will, taking some trusted server like IIS, getting
>>some code executed in its address space, patching code near where
>>a user context gets changed into (it just happens to be a DLL),
>>and execute code when someone logs into a private page (or better
>>still, snag their plaintext password). It's almost too easy.
>>WARNING: Be careful about running ISAPI applications on shared
>>server instances.
>
>I don't _think_ this is a problem. Might be worth looking at. However, if
>you let plain users give you executable content, the sky is the limit even
>without this technique. Bad enough trying to worry about various forms of
>server-side scripting.
>
>>So WindowsNT leaves a piece of memory wide open to reading and
>>writing that doesn't even contain _my_ data and then, in a context
>>of privilege, starts relying on code in that data range to execute
>>as designed?! Oversight or _deep_ design flaw?
>
>We don't know. Probably an oversight, but if this happens in many places,
>then I'd call it a fairly major screw-up.
>
>>Where else is this known to happen in NT? (Where is this not known
>>to happen but not known not to happen, if you get my drift?)
>
>It isn't. This is the first time we've seen this particular flavor of
>problem.
>
>>Does this mean that no Win32 programs that run with ANY sort of
>>privilege, be it user context, secret keys (ActiveX anyone?) or
>>business logic, can keep a secret if they load in evil DLL's?
>
>I don't think any app anywhere can save itself if it loads bad libraries.
>This is the way the telnet linker bug exploit works on UNIX - tell the
>system your libs live over here, then become root.
>
>
>David LeBlanc
>dleblanc@mindspring.com
>
>
>
David LeBlanc
dleblanc@mindspring.com
