exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

S-98-14.asc

S-98-14.asc
Posted Jan 10, 2000

Subject FreeBSD security compromise via mmap Date 13-Mar-98

systems | freebsd
SHA-256 | 85dc9a7a1cdaf34e1c4dadcc9301c96cf6df7a8de2a7604789514a1e24f67fc6

S-98-14.asc

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>> CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl. Links <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>> <<
>> CERT-NL also has stopped the CERT-CC-Mirror service. Due to this the <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the <<
>> complete CERT-CC advisory texts: http://www.cert.org <<
===============================================================================
===============================================================================
Security Advisory CERT-NL
===============================================================================
Author/Source : Egon Verharen Index : S-98-14
Distribution : World Page : 1
Classification: External Version: 1
Subject : FreeBSD security compromise via mmap Date : 13-Mar-98
===============================================================================

By courtesy of FreeBSD, Inc. we received information on a vulnerability in the
FreeBSD system.

CERT-NL recommends to install the patches.

==============================================================================
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/FreeBSD/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/FreeBSD/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/FreeBSD/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/FreeBSD/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.
=============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS
Phone: +31 302 305 305 BUSINESS HOURS ONLY
Fax: +31 302 305 329 BUSINESS HOURS ONLY
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands

NOODGEVALLEN: 06 22 92 35 64 ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64 ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IfjSYjBqwfc9jEQI8pQCfcyGZb24bfEoVDlkU6OCJPLLoTtsAmwXe
yo3e0ZoNPNyQzhgUT3yOgY2f
=QNmR
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close