From owner-freebsd-security Fri Feb 27 17:33:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16347 for freebsd-security-outgoing; Fri, 27 Feb 1998 17:33:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16283 for ; Fri, 27 Feb 1998 17:33:10 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id RAA32086; Fri, 27 Feb 1998 17:33:03 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaAkxa; Fri Feb 27 17:32:51 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id RAA00955; Fri, 27 Feb 1998 17:32:45 -0800 (PST) Message-Id: <199802280132.RAA00955@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd000944; Sat Feb 28 01:32:09 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: Eivind Eklund cc: Garrett Wollman , Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 17:09:54 +0100." <19980227170953.30435@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Feb 1998 17:32:08 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk I've managed to solve the problem while waiting in the doctor's office this afternoon. According to the 4.4BSD Bible, at securelevel > 0 /dev/mem and /dev/kmem are read only, which would break XIG's X server anyway. Securelevel 0 is used only in single user mode, so the XIG X server could only be used in securelevel -1. Here's a new copy of my hack of the OpenBSD patch. It only allows the insecure mmap access to character devices at securelevel -1. This seems like a good compromise because the XIG X server should be broken at securelevels 1 and 2 anyhow and to allow superuser to write to a read-only /dev/mem device at securelevel -1 doesn't add any new security exposures. --- sys/vm/vm_mmap.c.orig Mon Mar 24 20:54:29 1997 +++ sys/vm/vm_mmap.c Fri Feb 27 17:27:34 1998 @@ -230,6 +230,22 @@ flags |= MAP_ANON; } else { /* + * cdevs does not provide private mappings of any kind, + * except for superuser. Check for superuser to allow + * XIG X server to continue to work -- this is not a + * security hole because we only allow it to run at + * securelevel -1. Because the XIG X server writes + * directly to video memory via /dev/mem, it would + * never work at any other securelevel. + */ + if (securelevel == -1) + error = suser(p->p_ucred, &p->p_acflag); + else + error = 1; + if (vp->v_type == VCHR && error && + (flags & (MAP_PRIVATE|MAP_COPY))) + return (EINVAL); + /* * Ensure that file and memory protections are * compatible. Note that we only worry about * writability if mapping is shared; in this case, @@ -243,12 +259,19 @@ maxprot |= VM_PROT_READ; else if (prot & PROT_READ) return (EACCES); - if (flags & MAP_SHARED) { - if (fp->f_flag & FWRITE) - maxprot |= VM_PROT_WRITE; - else if (prot & PROT_WRITE) - return (EACCES); - } else + /* + * If we are sharing potential changes (either via MAP_SHARED + * or via the implicit sharing of character device mappings), + * and we are trying to get write permission although we + * opened it without asking for it, bail out. Check for + * superuser, only if we're at securelevel -1, to allow + * the XIG X server to continue to work. + */ + if (((flags & MAP_SHARED) != 0 || + (vp->v_type == VCHR && error)) && + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) + return (EACCES); + else maxprot |= VM_PROT_WRITE; handle = (caddr_t) vp; } Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca > On Fri, Feb 27, 1998 at 10:01:50AM -0500, Garrett Wollman wrote: > > < said: > > > > > crashes trying to access the VT. To get the XIG Accelerated X server > > > to work I've modified the patch to allow superuser to access to > > > character devices. > > > > The would be pointless. > > It'd kill the securelevel facility, but it would still remove the kmem > => root exploits. But it isn't good enough, I agree. Perhaps denying > the transition only when !(root || securelevel > -1) would be a > potential solution? It'd allow AccelX to keep working (AFAIK, it > won't work with securelevel > 0 anyway) and it would stop all real > violations I can think of > > 1. root can't lower the securelevel > 2. kmem can't get privileges it shouldn't have > 3. root will get some privileges it could get some privileges it would > have anyway if it had opened in another mode. This will make us > vulnerable to the unlikely exploit of somebody getting hold of a > root mmap() pointing at a character device, but _not_ being able to > execute arbitary code. Sounds unlikely to me. > > Have I covered everything? (Perhaps there are some special /dev/mem > interactions I don't know of...) > > Eivind, who don't really like this solution, either, but if the > alternative is leaving the bug wide open... > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message