Date: Fri, 27 Feb 1998 17:32:08 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: Eivind Eklund <eivind@yes.no> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem Message-ID: <199802280132.RAA00955@cwsys.cwsent.com> In-Reply-To: Your message of "Fri, 27 Feb 1998 17:09:54 %2B0100." <19980227170953.30435@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> > <<On Thu, 26 Feb 1998 20:23:06 -0800, Cy Schubert - ITSD Open Systems Group
<cschuber@uumail.gov.bc.ca> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802280132.RAA00955>