Re: [ NT SECURITY ALERT ] New Local GetAdmin Exploit

[dleblanc () MINDSPRING COM (David LeBlanc)]

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