From owner-freebsd-security  Mon Apr 28 05:24:20 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id FAA11400
          for security-outgoing; Mon, 28 Apr 1997 05:24:20 -0700 (PDT)
Received: from nic.follonett.no (nic.follonett.no [194.198.43.10])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA11392
          for <security@freebsd.org>; Mon, 28 Apr 1997 05:24:13 -0700 (PDT)
Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id OAA22722; Mon, 28 Apr 1997 14:21:50 +0200 (MET DST)
Received: from oo7 (pc136.dimaga.com [192.0.0.136]) by dimaga.com (8.7.5/8.7.2) with SMTP id MAA14994; Mon, 28 Apr 1997 12:02:33 +0200 (MET DST)
Message-Id: <3.0.32.19970428110452.00f97100@dimaga.com>
X-Sender: eivind@dimaga.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Apr 1997 11:04:53 +0200
To: Brian Buchanan <brian@wasteland.calbbs.com>
From: Eivind Eklund <eivind@dimaga.com>
Subject: Re: Lowering securelevel from userland
Cc: security@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 11:17 AM 4/26/97 -0700, Brian Buchanan wrote:
>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>

Here is a patch that _should_ fix it (2.1.7 sourcebase, as I'm not in the
vicinity of the -current sources right now.)

--- init.c.orig Mon Apr 28 11:52:04 1997
+++ init.c      Mon Apr 28 11:57:58 1997
@@ -235,7 +235,7 @@
         */
        handle(badsys, SIGSYS, 0);
        handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV,
-              SIGBUS, SIGXCPU, SIGXFSZ, 0);
+              SIGBUS, SIGXCPU, SIGXFSZ, SIGEMT, SIGQUIT, SIGTRAP, 0);
        handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, 0);
        handle(alrm_handler, SIGALRM, 0);
        sigfillset(&mask);

I can't test this patch, as I can't reboot the local server right now, and
doing remote experiments with init isn't my idea of 'safe'.
Please tell whether it seem to fix the problem, and I'll commit it if it does.
(After having done my own tests, too - init is critical...)

Eivind.