Re: [OT?] Replacing hacked binaries
Quoting Jan Martin Mathiassen (debian@TGR.yi.org):
> list. it was supposed to go to debian-security, not debian-devel. i need
debian-devel removed from the Cc list.
> if you want to know what was changed, you use tripwire (well, everyone
> should do that anyway). that util shows changed, deleted, added, etc...
> the usual shit. of course, the database will have to be kept off of the
> box in question (since, again, tripwire could be re-run to cover up his
> tracks)...
If you keep the tripwire database off the box, tripwire can't use it to
check the binaries. The database should be created once, on a freshly (but
finished) install, and be burned on a cd-rom or rewritable (if you use a RW,
don't keep it in the writer ;) )
> of course, it *is* possible, but still... you *know* someone hacked your
> computer, and you *know* they left a backdoor. but do you know if you
> found *all* of them? unless you're running tripwire, no, and even then
> they can leave backdoors somewhere tripwire isn't watching (imagine
> monitoring /var/log... :).
Even when you're running tripwire, it's quite simple to fool things. Job de
Haas has made a kernel module for Solaris (kmod), that can hide processes,
and subsequently hide files for non-hidden processes.
It can also give filehandles to different files depending on if they're
opened or executed, or whatever system call tries to access them.
Tripwire will not see this.
I _know_ there is at least one linux kernel module that does all of this.
> the main issue i'm trying to point out here is, configs, homedirs and
> trust are the important part of a linux install. that's where all the hard
> work lie. that's where the differences between linux systems are. the rest
> of it is just bog-standard, and can easily be replaced at the blink of an
> eye. i mean, a normal debian install here takes what? 45 minutes
> (including kernel compile... on a p200 :). compare that to several hours,
> maybe DAYS spent comparing, wondering and worrying.
There is a lot of stuff that is not configfile or homedir, that doesn't take
the blink of an eye to replace ;)
> returning to your initial idea (just to make this post fit in on devel :),
> what if we were to extend that idea, and add md5 sums to every file in a
> .deb, so we could use dpkg to check the validity of a package by doing
> dpkg --validate <moo>?
Isn't the md5 on a complete package enough ? If we worry that much about
integrity of files in a package, i think we'd better look at a different
problem; NMU's and non-trustworthy Debian programmers (or upstream authors)
(don't worry - i'm not saying there are any, but we're talking about healthy
paranoia here)
The moment somebody uploads a package of mine, with a suid binary that
executes a shell in it - who's to notice ? If the maintainer is not as
active as he/she should be, chances are that by the time the problem has
been fixed, _lots_ of boxes have security leaks.
I worry about stuff like that more than the checksums of individual files in
packages.
Greets,
Robert
--
| rvdm@cistron.nl - Cistron Internet Services - www.cistron.nl |
| php3/c/perl/html/c++/sed/awk/linux/sql/cgi/security |
| My statements are mine, and not necessarily cistron's. |
"Invalid element 'rvdm' in content of 'p'." (WAP emulator error)
Reply to: