From owner-freebsd-security Sat Jun 19 0:50:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) by hub.freebsd.org (Postfix) with ESMTP id 2ED8114DD5 for ; Sat, 19 Jun 1999 00:50:32 -0700 (PDT) (envelope-from brian@CSUA.Berkeley.EDU) Received: from smarter.than.nu (pm0-8.vpop1.avtel.net [207.71.237.8]) by beach.silcom.com (Postfix) with ESMTP id 0131F861 for ; Sat, 19 Jun 1999 00:50:28 -0700 (PDT) Date: Sat, 19 Jun 1999 00:50:28 -0700 (PDT) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: freebsd-security@freebsd.org Subject: securelevel and mount_union Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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