Hi Drew, Thanks, yet another really well informed and thoughtful response. I sure am happy to have twigged all this good thinking. >As for Unix and the potential impracticality of sandtrapping system calls... I might note that >Unix already has some effective solutions for these issues, as Dave Ahmad pointed out to me several >months ago (and has held me fascinated ever since): >Unix has similiar systems of this kind, which Provos links to. Window's has a few applications of >limited capability which trap NT api calls. hoglund's rootkit demonstrates this (I mentioned another, different, rootkit in a earlier post, hoglund traps calls using a kernel mode driver, whereas that one patches API functions in user mode) >dealing with the problem... they make a signature of the firewall tester itself and ban it based on >that signature. Which is clearly bullshit, and something consumers should be aware of, and not stand for. Period. >But, maybe someone has a better solution for a strong Application Firewall out there, besides the >ones we have mentioned (varieties hashing of in process memory and gating system calls). Another possible solution would be to hook relevant API calls in system DLLs, and then disable the use of VirtualProtectEx to enable writing over the memory occupied by those functions. It would still be possible to execute the first few instructions of the API call yourself, and then JMP into the call below the hook, though. I think this is generally a problem with hardening system calls in user-mode ... Ultimately you can just implement everything up to the transition into kernel mode and bypass any user-mode hook. Hashing all of a process's code pages seems like a very hard thing to do. Anyone got a suggestion along these lines? Cheers, ~ol
