Full Disclosure mailing list archives
sandboxing
From: lcamtuf () ghettot org (Michal Zalewski)
Date: Sun, 15 Sep 2002 20:31:21 -0400 (EDT)
On Sun, 15 Sep 2002 silvio () big net au wrote:
because.. a binary that runs knows about all the shared libraries involved. look at the link map list.. you can just count them, and if you have too many.. something is whack.
Forensics of binaries by running it at full speed under a software tracer tool of any kind is extremely convinient, but also it is a very bad idea, regardless of the tool you have. Heck, it's not always a good idea to run a tool under a step-by-step debugger; back in DOS times, there were quite a few self-modifying applications that were able to fool certain debuggers big time. Run-time analysis works as long as you can outsmart the bad guy - but as soon as he gets clever enough to detect the tool (or a general approach) you're using, you have no way of telling he's not pulling your leg by controlling your tracer, or not running a slightly different code that has one subtle, but important change. And, face it, just using strace / ltrace / LD_PRELOAD / ld.so.preload and hoping he wouldn't notice is pretty much an insult for the attacker. Yes, they typically do not check for that, but a typical *nix worm is still fairly primitive - it's changing, however. I'm surprised how slowly this is happening, but I guess the main contributing factor is that so many boxes that are very low-effort targets with inexperienced admins - thus, there's no real need to design very stealth, portable and smart 0-day worms just to compromise 100,000 computers, more than enough to cause serious havoc and to DDoS CNN. Face it - characteristics of the environment WILL change when you observe it in software (hardware tools have other problems, no need to elaborate). Typical tools have a very limited number of methods to use - kernel-level breakpoints/traps, in two flavors - ptrace or your own version of the same thing; or in-code breakpoints / traps. All those affect some parameters of the environment and can be detected in standard ways. And no, even solutions like running user-space Linux or VMWare under a tracer are, in my humble and erroneous opinion, not exactly undetectable. But I admit to being wrong already, please call back your lawyers. So far, the general approach many people have chosen for *nix anti-debugging is to simply "go nowhere" when a debugger is detected - crash, exit, trash the debugger - making it apparent there's an anti-debugging routine. If such a code was well-hidden and would decide about calling some obscure, self-modifying subroutine, perhaps not even contained within the binary itself, I wonder how many people would miss it. It is the author's courtesy to let you know there's an anti-debugging code that detected your debugger / tracer, period. Don't take it for granted ;> -- m
Current thread:
- sandboxing silvio () big net au (Sep 15)
- sandboxing Michal Zalewski (Sep 15)
- sandboxing silvio () big net au (Sep 15)
- sandboxing Michal Zalewski (Sep 15)