Date: Thu, 5 Oct 2000 02:23:42 -0400 From: Hank Leininger <freebsd-security@progressive-comp.com> To: freebsd-security@FreeBSD.ORG Subject: Re: BSD chpass (fwd) Message-ID: <200010050623.CAA05646@mailer.progressive-comp.com>
next in thread | raw e-mail | index | archive | help
On 2000-10-04, Kris Kennaway <kris@FreeBSD.ORG> wrote:
> On Wed, Oct 04, 2000 at 10:47:15AM -0400, Garrett Wollman wrote:
> > <<On Wed, 4 Oct 2000 02:32:49 -0700, Kris Kennaway <kris@FreeBSD.ORG>
> > said:
> > > I think you're right. Which is a good reason why your /usr/bin
> > > should be schg too ;-)
> >
> > Actually, sappnd on all the directories which might be in (or on the
> > way to) root's path would be enough.
> Except you can still just mount a doctored copy over the top of it :-)
Keep in mind that a patient attacker can simply leave an egg and wait for
you to boot single-user. For instance, suppose /bin is in root's path
before /usr/bin, both are sappnd (but not schg), and we've been careful
with schg'ing rc scripts (and all commands they call), somehow ruled out
other nice mount(2) games, etc. If one's gotten root on such a system with
securelevel raised, simply place a trojan'ed 'more', 'head', 'tail', or
even 'vi' binary in /bin and wait for the next time the box is rebooted
single-user and root logs in w/o securelevel raised (they could accelerate
matters by subsequently feeding overrun-looking logs to syslog and/or
crashing the box, causing curious admins to boot single-user and
investigate, tail logfiles, etc). Does everybody type the full path to
every executable they run every time? Doubtful ;)
I've a feeling I'm (re)stating the obvious, but IMHO securelevels can't
really permanently preserve a system's known-good state in the face of root
compromise unless literally everything you'd ever access w/o securelevels
raised, is fully protected when they are (in which case you'll effectively
have everything interesting RO -- just set the RO jumper on the drive while
you're at it). Otherwise there will always(?) be some extra-mile way to
circumvent them. Of course we can devise countermeasures ad-nauseum -- for
instance, set all dirs in root's path to schg and only set sappnd on the
"last" one, and never change the order (silly). Or from every directory
"higher" in the path than a path'ed command, create a symlink to the right
place (unspeakably ugly, but works ;) Though you'll still have the 'sl',
'ls-l', etc trojan possibilities either way.
And this isn't to say that I think securelevel efforts are wasted. The bar
is raised; this is good, period ("how much higher is it when you are done"
is still an open question though IMHO). Userland integrity checkers a la
tripwire are useful again in a system which can guarantee a)without a
reboot, the kernel cannot be modified nor raw-device disk or memory access
obtained, and b)at least some minimal set of files (the static binaries,
and their config/database files) have not been tampered with in any way.
Without these, LKM-based rootkits make traditional integrity checkers
pretty useless. ...A system whose integrity checkers are properly
preserved can be expected to work as advertised (until reboot ;). One
which alerted on the addition of new binaries would detect the above.
Unless the attacker places the egg and then halts the box quickly enough
that the integrity checker doesn't get a chance to run before the crash,
and the admin checks things out booted to single-user mode, when it may not
have launched yet...
--
Hank Leininger <hlein@progressive-comp.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010050623.CAA05646>