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(). 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:10:20 PDT