Re: Recognizing compromised binaries

[dbrez () AMAZON COM (Dominique Brezinski)]

At 09:59 AM 2/23/00 -0800, David Brumley wrote:
> We little toolbox's of compiled binaries (some static...not all because
> static semantics don't always work, esp. when trying to figure out a name
> that goes w/ a process. trivial mod, I know but it's worked great to date)
> at: http://security.stanford.edu/binaries/
>
> Some of the directories are restricted per licensing (aka our license w/
> sun), but linux is there.  I just do a:
> mkdir /tmp/sec
> cd /tmp/sec
> tar zxvf anti-rootkit.tgz
> chmod 500 *
> export PATH=/tmp/sec:${PATH}

I would recommend unsetting LD_LIBRARY_PATH, LD_PRELOAD, and any other LD_
environment variables that may be defined in your environment prior to
executing anything from your tool kit.  I would include known good copies
of *all* shared objects that your tools require in your tool kit, and then
set LD_LIBRARY_PATH to point to your shared object directory.  This will
help stop the dynamic linker from loading potentially trojaned shared
objects into your trusted tools.  This method is not fool-proof, but much
better than nothing.  You *never* can be sure your trusted tools are really
trustworthy, unless you *know* the kernel has not been modified and you
supply *all* the user land code you use (including a known good copy of
your shell).  Obviously this is pretty hard on any real system today.  This
will get you past 98% of the stuff attackers leave behind, but there are
always those smarter than you and I :(

---
Dominique Brezinski             Amazon.com Security
office (206) 266-6900           pager (888) 916-2747
8312 ADAB C5B2 1916 CBD8  150E 37CE 044E F45F B5E4