From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: sandboxing

On Sun, 15 Sep 2002 silvio@....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

Powered by blists - more mailing lists