RE: [OT?] Replacing hacked binaries
> > 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 ;) )
erm, heh. bad wording on my part. i meant "move a backup copy off of the
box".
> 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.
great. even *more* i didn't think off at first. i've actually seen that
patch (quite neat, but not what i would usually run... i'm not *that*
paranoid, contrary to the paranoid tone of my previous letter). okay, let's
see. we take the box offline, boot up with a clean kernel, copy tripwire + a
known good database, run and compare. voila, that problem solved.
> There is a lot of stuff that is not configfile or homedir, that
> doesn't take
> the blink of an eye to replace ;)
i'm at a loss as to what this could be, but i'll take your word for it.
> 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)
it was really more of a random thought (not 100% serious). i mean, we *have*
tripwire, and it works *great*... so why add md5sum to dpkg, indeed. i mean,
we'd have to add exceptions to conf files, etc etc etc, and it'd all just be
a kludge.
> (don't worry - i'm not saying there are any, but we're talking
> about healthy paranoia here)
agreed. i trust (maybe foolishly, but still..) that any package in debian
isn't designed as a rootkit in and of itself (altho, as the traceroute
vulnerability has shown, it may be, unwillingly and unknowingly), and that
it'll be found out and removed/fixed if it is.
then again, i don't use that many weird packages lately, so i guess that is
moot.
> 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.
again, agreed. it was really more as a random "wouldn't-this-be-neat"
feature idea than a serious "this-should-be-in-dpkg" feature idea.
-m
When you are having a bad day, and it seems like everybody is trying to piss
you off, remember that it takes 42 muscles to produce a frown, but only 4
muscles to work the trigger of a good sniper rifle.
Reply to: