FreeBSD Security Officer
1998-Mar-12 11:47 UTC
FreeBSD Security Advisory: FreeBSD-SA-98:02.mmap
-----BEGIN PGP SIGNED MESSAGE-----
============================================================================FreeBSD-SA-98:02
Security Advisory
FreeBSD, Inc.
Topic: security compromise via mmap
Category: core
Module: kernel
Announced: 1998-03-12
Affects: FreeBSD 2.2.*, FreeBSD-stable and FreeBSD-current
before 1998/03/11 suffer from this problem.
Corrected: FreeBSD-current as of 1998/03/11
FreeBSD-stable as of 1998/03/11
FreeBSD only: no (also other 4.4BSD based systems may be affected)
Patches: ftp://ftp.freebsd.org/pub/CERT/patches/SA-98:02/
============================================================================IMPORTANT
MESSAGE: The FreeBSD advisory archive has moved from
ftp://freebsd.org/pub/CERT to ftp://ftp.freebsd.org/pub/CERT
============================================================================
I. Background
The 4.4BSD VM system allows files to be "memory mapped", which
causes the specified contents of a file to be made available
to a process via its address space. Manipulations of that file
can then be performed simply by manipulating memory, rather
than using filesystem I/O calls. This technique is used to
simplify code, speed up access to files, and provide interprocess
communication.
II. Problem Description
Due to a 4.4BSD VM system problem, it is possible to memory-map
a read-only descriptor to a character device in read-write
mode.
III. Impact
The hole can be used by members of group kmem to gain superuser
privileges. It also allows the superuser to lower the system
securelevel.
IV. Workaround
No workaround is known.
V. Solution
Apply one of the following patches, rebuild your kernel,
install it and reboot your system.
The patches below can be found on
ftp://ftp.freebsd.org/pub/CERT/patches/SA-98:02/
Patch for 3.0-current systems:
Index: vm_mmap.c
================================================================== RCS file:
/home/cvsup/freebsd/CVS/src/sys/vm/vm_mmap.c,v
retrieving revision 1.74
diff -u -r1.74 vm_mmap.c
--- vm_mmap.c 1998/03/07 21:37:01 1.74
+++ vm_mmap.c 1998/03/10 21:51:30
@@ -162,6 +162,7 @@
vm_prot_t prot, maxprot;
void *handle;
int flags, error;
+ int disablexworkaround;
off_t pos;
addr = (vm_offset_t) uap->addr;
@@ -252,6 +253,26 @@
pos = 0;
} else {
/*
+ * cdevs does not provide private mappings of any kind.
+ */
+ /*
+ * However, for XIG X server to continue to work,
+ * we should allow the superuser to do it anyway.
+ * We only allow it at securelevel < 1.
+ * (Because the XIG X server writes directly to video
+ * memory via /dev/mem, it should never work at any
+ * other securelevel.
+ * XXX this will have to go
+ */
+ if (securelevel >= 1)
+ disablexworkaround = 1;
+ else
+ disablexworkaround = suser(p->p_ucred,
+ &p->p_acflag);
+ if (vp->v_type == VCHR && disablexworkaround &&
+ (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,
@@ -265,12 +286,20 @@
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 && disablexworkaround)) &&
+ (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) !=
0)
+ return (EACCES);
+ else
maxprot |= VM_PROT_WRITE;
handle = (void *)vp;
}
Patch for 2.2 systems:
Index: vm_mmap.c
================================================================== RCS file:
/home/cvsup/freebsd/CVS/src/sys/vm/vm_mmap.c,v
retrieving revision 1.53.2.2
diff -u -r1.53.2.2 vm_mmap.c
--- vm_mmap.c 1997/03/25 04:54:29 1.53.2.2
+++ vm_mmap.c 1998/03/10 21:50:46
@@ -157,6 +157,9 @@
vm_prot_t prot, maxprot;
caddr_t handle;
int flags, error;
+ int disablexworkaround;
+
+ addr = (vm_offset_t) uap->addr;
prot = uap->prot & VM_PROT_ALL;
flags = uap->flags;
@@ -230,6 +233,26 @@
flags |= MAP_ANON;
} else {
/*
+ * cdevs does not provide private mappings of any kind.
+ */
+ /*
+ * However, for XIG X server to continue to work,
+ * we should allow the superuser to do it anyway.
+ * We only allow it at securelevel < 1.
+ * (Because the XIG X server writes directly to video
+ * memory via /dev/mem, it should never work at any
+ * other securelevel.
+ * XXX this will have to go
+ */
+ if (securelevel >= 1)
+ disablexworkaround = 1;
+ else
+ disablexworkaround = suser(p->p_ucred,
+ &p->p_acflag);
+ if (vp->v_type == VCHR && disablexworkaround &&
+ (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 +266,20 @@
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 && disablexworkaround)) &&
+ (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) !=
0)
+ return (EACCES);
+ else
maxprot |= VM_PROT_WRITE;
handle = (caddr_t) vp;
}
VI. Thanks
This advisory is based on the OpenBSD Security Advisory, dated
February 20 2, 1998. Thanks to "Thomas H. Ptacek"
<tqbf@enteract.com>
for allowing this.
Thanks to "Cy Schubert" <cschuber@uumail.gov.bc.ca> for
porting the
OpenBSD patch to FreeBSD.
============================================================================FreeBSD,
Inc.
Web Site: http://www.freebsd.org/
Confidential contacts: security-officer@freebsd.org
PGP Key: ftp://ftp.freebsd.org/pub/CERT/public_key.asc
Security notifications: security-notifications@freebsd.org
Security public discussion: security@freebsd.org
Notice: Any patches in this document may not apply cleanly due to
modifications caused by digital signature or mailer software.
Please reference the URL listed at the top of this document
for original copies of all patches if necessary.
============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNQg5QlUuHi5z0oilAQGxJQP/YRbQ4Ox0R7zELYIfiYY4ZTec53DlkNTm
+NWLqqMJWFAQQ2BfTLmcxJdcaUlPkZmKU21ZUFVxKFuCjjp1MSiFApLJRcXuX6u6
ZYgwvrrLB5ppU2L/uWG+mlJKrf/j6R28B/NQ7b/OB9hcRlNdOFyu7K44M+yKxaPb
SRJ4LR1rQKk=qDrb
-----END PGP SIGNATURE-----
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org
To unsubscribe from freebsd-announce, send a mail to
majordomo@freebsd.org with the body
unsubscribe freebsd-announce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-announce" in the body of the message
FreeBSD Security Officer
1998-Mar-16 11:21 UTC
FreeBSD Security Advisory: FreeBSD-SA-98:02.mmap
-----BEGIN PGP SIGNED MESSAGE----- Recently, the FreeBSD CERT archive has been moved. The move has been announced in the latest 2 advisories, SA-98:01 and SA-98:02. Unfortunately, an error was made in both advisories, so the wrong location was published. The correct location of the FreeBSD advisory archive is now: ftp://ftp.freebsd.org/pub/FreeBSD/CERT ============================================================================The FreeBSD Project, Inc. Web Site: http://www.freebsd.com/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc ============================================================================ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNQ17cFUuHi5z0oilAQGszgP/Qci+Ti40fIPtkphfQRPTyBBpDP8rmr8j uk4gcAO9wLGqMJ25imPPuDVSJ3H6RDIFoQmTbi7QkHYCjD+kn7+haOm6M28Y78iF 9Yy0josdgUpPdEXc1kpnAgt3cvwlz0ZJnCbx8CjFLpjrM2plWdlksfd7mX5tt3c+ f1ARitF5IuU=X76C -----END PGP SIGNATURE----- This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To unsubscribe from freebsd-announce, send a mail to majordomo@freebsd.org with the body unsubscribe freebsd-announce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-announce" in the body of the message
-----BEGIN PGP SIGNED MESSAGE-----
============================================================================FreeBSD-SA-98:02
Security
Advisory
FreeBSD,
Inc.
Topic: security compromise via mmap
Category: core
Module: kernel
Announced: 1998-03-12
Affects: FreeBSD 2.2.*, FreeBSD-stable and FreeBSD-current
before 1998/03/11 suffer from this problem.
Corrected: FreeBSD-current as of 1998/03/11
FreeBSD-stable as of 1998/03/11
FreeBSD only: no (also other 4.4BSD based systems may be affected)
Patches: ftp://ftp.freebsd.org/pub/CERT/patches/SA-98:02/
============================================================================IMPORTANT
MESSAGE: The FreeBSD advisory archive has moved from
ftp://freebsd.org/pub/CERT to ftp://ftp.freebsd.org/pub/CERT
============================================================================
I. Background
The 4.4BSD VM system allows files to be "memory mapped", which
causes the specified contents of a file to be made available
to a process via its address space. Manipulations of that file
can then be performed simply by manipulating memory, rather
than using filesystem I/O calls. This technique is used to
simplify code, speed up access to files, and provide interprocess
communication.
II. Problem Description
Due to a 4.4BSD VM system problem, it is possible to memory-map
a read-only descriptor to a character device in read-write
mode.
III. Impact
The hole can be used by members of group kmem to gain superuser
privileges. It also allows the superuser to lower the system
securelevel.
IV. Workaround
No workaround is known.
V. Solution
Apply one of the following patches, rebuild your kernel,
install it and reboot your system.
The patches below can be found on
ftp://ftp.freebsd.org/pub/CERT/patches/SA-98:02/
Patch for 3.0-current systems:
Index: vm_mmap.c
================================================================== RCS file:
/home/cvsup/freebsd/CVS/src/sys/vm/vm_mmap.c,v
retrieving revision 1.74
diff -u -r1.74 vm_mmap.c
--- vm_mmap.c 1998/03/07 21:37:01 1.74
+++ vm_mmap.c 1998/03/10 21:51:30
@@ -162,6 +162,7 @@
vm_prot_t prot, maxprot;
void *handle;
int flags, error;
+ int disablexworkaround;
off_t pos;
addr = (vm_offset_t) uap->addr;
@@ -252,6 +253,26 @@
pos = 0;
} else {
/*
+ * cdevs does not provide private mappings of any kind.
+ */
+ /*
+ * However, for XIG X server to continue to work,
+ * we should allow the superuser to do it anyway.
+ * We only allow it at securelevel < 1.
+ * (Because the XIG X server writes directly to video
+ * memory via /dev/mem, it should never work at any
+ * other securelevel.
+ * XXX this will have to go
+ */
+ if (securelevel >= 1)
+ disablexworkaround = 1;
+ else
+ disablexworkaround = suser(p->p_ucred,
+ &p->p_acflag);
+ if (vp->v_type == VCHR && disablexworkaround &&
+ (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,
@@ -265,12 +286,20 @@
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 && disablexworkaround)) &&
+ (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) !=
0)
+ return (EACCES);
+ else
maxprot |= VM_PROT_WRITE;
handle = (void *)vp;
}
Patch for 2.2 systems:
Index: vm_mmap.c
================================================================== RCS file:
/home/cvsup/freebsd/CVS/src/sys/vm/vm_mmap.c,v
retrieving revision 1.53.2.2
diff -u -r1.53.2.2 vm_mmap.c
--- vm_mmap.c 1997/03/25 04:54:29 1.53.2.2
+++ vm_mmap.c 1998/03/10 21:50:46
@@ -157,6 +157,9 @@
vm_prot_t prot, maxprot;
caddr_t handle;
int flags, error;
+ int disablexworkaround;
+
+ addr = (vm_offset_t) uap->addr;
prot = uap->prot & VM_PROT_ALL;
flags = uap->flags;
@@ -230,6 +233,26 @@
flags |= MAP_ANON;
} else {
/*
+ * cdevs does not provide private mappings of any kind.
+ */
+ /*
+ * However, for XIG X server to continue to work,
+ * we should allow the superuser to do it anyway.
+ * We only allow it at securelevel < 1.
+ * (Because the XIG X server writes directly to video
+ * memory via /dev/mem, it should never work at any
+ * other securelevel.
+ * XXX this will have to go
+ */
+ if (securelevel >= 1)
+ disablexworkaround = 1;
+ else
+ disablexworkaround = suser(p->p_ucred,
+ &p->p_acflag);
+ if (vp->v_type == VCHR && disablexworkaround &&
+ (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 +266,20 @@
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 && disablexworkaround)) &&
+ (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) !=
0)
+ return (EACCES);
+ else
maxprot |= VM_PROT_WRITE;
handle = (caddr_t) vp;
}
VI. Thanks
This advisory is based on the OpenBSD Security Advisory, dated
February 20 2, 1998. Thanks to "Thomas H. Ptacek"
<tqbf@enteract.com>
for allowing this.
Thanks to "Cy Schubert" <cschuber@uumail.gov.bc.ca> for
porting the
OpenBSD patch to FreeBSD.
============================================================================FreeBSD,
Inc.
Web Site: http://www.freebsd.org/
Confidential contacts: security-officer@freebsd.org
PGP Key:
ftp://ftp.freebsd.org/pub/CERT/public_key.asc
Security notifications: security-notifications@freebsd.org
Security public discussion: security@freebsd.org
Notice: Any patches in this document may not apply cleanly due to
modifications caused by digital signature or mailer software.
Please reference the URL listed at the top of this document
for original copies of all patches if necessary.
============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNQg5QlUuHi5z0oilAQGxJQP/YRbQ4Ox0R7zELYIfiYY4ZTec53DlkNTm
+NWLqqMJWFAQQ2BfTLmcxJdcaUlPkZmKU21ZUFVxKFuCjjp1MSiFApLJRcXuX6u6
ZYgwvrrLB5ppU2L/uWG+mlJKrf/j6R28B/NQ7b/OB9hcRlNdOFyu7K44M+yKxaPb
SRJ4LR1rQKk=qDrb
-----END PGP SIGNATURE-----
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org
To unsubscribe from freebsd-announce, send a mail to
majordomo@freebsd.org with the body
unsubscribe freebsd-announce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-announce" in the body of the message
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-announce" in the body of the message