Date: Sat, 26 Apr 1997 11:17:51 -0700 (PDT) From: Brian Buchanan <brian@wasteland.calbbs.com> To: security@freebsd.org Subject: Lowering securelevel from userland Message-ID: <Pine.BSF.3.96.970426103543.163A-100000@thought.calbbs.com>
index | next in thread | raw e-mail
Description:
On my 2.2.1 system, I was able to lower the securelevel by taking over
init with gdb. I compiled a copy of init with debug symbols by using
-ggdb in the compile flags, then ran gdb using that for the symbol table
and attached to process 1. I was able to execute setsecuritylevel(0) from
gdb, although this caused the process to hang. Sending a signal woke it
up long enough to let the securelevel get changed from 2 to 0 before init
died with a segmentation fault. Even though the system was in an unstable
state, I was able to remove the schg flags from /kernel and /sbin/init
before rebooting the machine from the command line.
Impact:
An attacker who has gained superuser privilages can replace the kernel,
delete append-only logs, or thrash the disks, even on a system that
normally runs in highly secure mode.
Exploit:
One can do the following as the superuser to gain total control of a
machine running at securelevel 1 or 2.
gdb /usr/src/sbin/init/init.debug 1 (Attach to process 1, loading
symbols from init compiled w/ -ggdb)
signal SIGHUP (Process will get SIGHUP when it resumes)
call setsecuritylevel(0) (Make init lower the security level)
<security level will change to 0, init will segfault>
<suspend gdb or switch to another root shell, remove schg/sappnd
flags from files, reboot the machine>
--
Brian Buchanan Mail: brian@calbbs.com
UNIX sysadmin, webmaster webmaster@calbbs.com
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970426103543.163A-100000>