[4792] in bugtraq

home help back first fref pref prev next nref lref last post

Re: [ADVISORY] 4.4BSD Securelevels

daemon@ATHENA.MIT.EDU (Charles M. Hannum)
Wed Jun 25 20:23:15 1997

Date: 	Wed, 25 Jun 1997 07:30:18 -0400
Reply-To: "Charles M. Hannum" <mycroft@GNU.AI.MIT.EDU>
From: "Charles M. Hannum" <mycroft@GNU.AI.MIT.EDU>
X-To:         tqbf@enteract.com
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  "Thomas H. Ptacek"'s message of Tue, 24 Jun 1997 18:49:44 -0500

While we appreciate being alerted to this problem[*], I am compelled
to point out that this change is insufficient, in that it does not
protect writes to the init process's registers.  This is rather easy
to exploit on many CPUs by just setting the PC to point to
setsecuritylevel() while there's a non-positive number at the top of
the stack.  I'll leave the exploit as an exercise for the reader.

Here's a patch for NetBSD which fixes this:

-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----
Index: procfs_subr.c
===================================================================
RCS file: /cvsroot/src/sys/miscfs/procfs/procfs_subr.c,v
retrieving revision 1.18
diff -c -2 -r1.18 procfs_subr.c
*** procfs_subr.c       1997/05/05 07:35:13     1.18
--- procfs_subr.c       1997/06/25 11:17:52
***************
*** 222,225 ****
--- 222,242 ----

        switch (pfs->pfs_type) {
+       case Pregs:
+       case Pfpregs:
+       case Pmem:
+               /*
+                * Do not allow init to be modified while in secure mode; it
+                * could be duped into changing the security level.
+                */
+               if (uio->uio_rw == UIO_WRITE &&
+                   p == initproc && securelevel > -1)
+                       return (EPERM);
+               break;
+
+       default:
+               break;
+       }
+
+       switch (pfs->pfs_type) {
        case Pnote:
        case Pnotepg:
-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----

[*] Well, we *would* have appreciated it, except that nobody actually
bothered to contact us.  It's somewhat duplicitous to publish an
advisory mentioning other systems without making any attempt to get
the other vendors' input.

home help back first fref pref prev next nref lref last post