Re: [ADVISORY] 4.4BSD Securelevels

Charles M. Hannum (mycroft@GNU.AI.MIT.EDU)
Wed, 25 Jun 1997 07:30:18 -0400

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.