Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jun 1999 00:50:28 -0700 (PDT)
From:      "Brian W. Buchanan" <brian@CSUA.Berkeley.EDU>
To:        freebsd-security@freebsd.org
Subject:   securelevel and mount_union
Message-ID:  <Pine.BSF.4.05.9906190023120.70357-100000@smarter.than.nu>

next in thread | raw e-mail | index | archive | help
Even on a system well locked-down with schg flags and use of a positive
securelevel, it is possible for an attacker who has gained root to replace
system binaries and cover his tracks through the use of mount_union.
mount_union continues to function normally even on mountpoints with the
schg flag set and while the system is running at securelevel 2.  (Tested
only on -stable, however.)

To exploit this, the attacker can simply create his own version of /bin or
another directory elesewhere in the filesystem and "mount_union
/some/obscure/place /bin". If mount itself is shadowed by a modified
version which conceals the union mounts from the usual status report, it
is quite likely that this could remain unnoticed for some time.  
Meanwhile, modified versions of /usr/bin/login, telnet, ssh, etc. are
quietly recording local and remote passwords...  Tripwire and/or its
associated data files could also be shadowed, further reducing the chance
of detection.

The union mounts will of course disappear upon system shutdown, but even
if the attacker cannot modify fstab or place an entry in the real version
of any of the system startup scripts, this ruse can be reinstated
post-reboot by an entry in root's crontab or login script, or anything
else not set immutable that might execute with root permissions sometime
shortly after reboot.

My suggestion: Either cause a positive securelevel setting to disable
the functionality of mount_union and mount -o union, or disable this
functionality for mountpoints with the schg flag set.  (In the latter
case, the sysadmin must be careful to set the schg flag on all parent
directories of any directory containing files with schg set, as well as
the file's directory)

-- 
Brian Buchanan                                     brian@CSUA.Berkeley.EDU
--------------------------------------------------------------------------
FreeBSD - The Power to Serve!                       http://www.freebsd.org

daemon(n): 1. an attendant power or spirit : GENIUS
           2. the cute little mascot of the FreeBSD operating system



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?Pine.BSF.4.05.9906190023120.70357-100000>