This appears to have been lost in the mail spool snafu. >From: dleblancat_private >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 >dleblancat_private > > > David LeBlanc dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:12:21 PDT