Date: Fri, 20 Nov 1998 21:11:51 +0100 (CET) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: FreeBSD Current <current@FreeBSD.ORG>, FreeBSD Current <current@FreeBSD.ORG>, FreeBSD Security <security@FreeBSD.ORG> Subject: FW: NetBSD Security Advisory 1998-005 Message-ID: <XFMail.981120211151.asmodai@wxs.nl>
next in thread | raw e-mail | index | archive | help
Might be interesting,
I sended it to Current as well regarding the mentioning of mmap (dying Daemons
mayhaps?) Sorry if that was not appropriate, but to me it seemed that way...
FYI,
-----FW: <24978.911534701@eterna.com.au>-----
Date: Fri, 20 Nov 1998 15:05:01 +1100
Sender: netbsd-announce-owner@netbsd.org
From: matthew green <mrg@eterna.com.au>
To: netbsd-announce@netbsd.org
Subject: NetBSD Security Advisory 1998-005
Cc: tech-security@netbsd.org, current-users@netbsd.org, bugtraq@netspace.org,
cert@cert.org, auscert@auscert.org.au
-----BEGIN PGP SIGNED MESSAGE-----
NetBSD Security Advisory 1998-005
---------------------------------
Topic: Problem with mmap(2) and many drivers.
Version: NetBSD 1.3.2 and prior; NetBSD-current to 19981120.
Severity: Local users may be able to access physical and device
memory or cause system instability.
Abstract
- --------
Many character device drivers that provide mmap access do not properly
bounds check their arguments. The impact of this varies widely across
each affected driver. Some drivers allow access to portions of physical
or device memory or may cause the system to panic or act unreliably.
Technical Details
- -----------------
The NetBSD character device d_mmap driver-provided service entry is
called by the device page fault routine to check for valid access and
return a machine dependant value (normally a physicaly address or a page
frame number) used to create a virtual to physical address mapping. One
of the arguments to the d_mmap() routine is `int offset;' which is a
signed value. Many of the device drivers which implement mmap access
do not properly check for negative values, each having different
failure modes.
For example, on NetBSD/i386 the text console drivers can be fooled
into allowing the console user access to physical memory from 0 to
640KB, but on NetBSD/macppc, the console driver may allow the console
user access to any memory location.
The NetBSD d_mmap interface was inherited by NetBSD from 4.4BSD, and
there may be problems in other 4.4BSD derived operating systems.
Solutions and Workarounds
- -------------------------
NetBSD 1.3.2 users should upgrade to NetBSD 1.3.3 when it becomes
available, or apply the following patch to their kernel source and
rebuild their kernel.
ftp://ftp.netbsd.org/pub/NetBSD/misc/security/patches/19981120-d_mmap
NetBSD-current users should update to a source tree newer than
19981120 and rebuild their kernel.
If these actions can not be taken, the following section can be used to
remove access to devices at the file system level, on a per-port and
per-device basis.
Port and Device Specific Details
- --------------------------------
Below are the NetBSD port and device specific details for each of the
affected drivers. These do not list `attacks' possible for someone who
is already root, or do not elevate current access. This list may be
incomplete or even incorrect; the best efforts have been made to ensure
its accuracy in the time permitted.
NetBSD/arm32 and NetBSD/i386 specific problems:
The pccons and pcvt console drivers allow access from 0 to
the base address of video memory (640KB). These drivers must
be associated with the system console and are normally only
exploitable to the user logged in on the console.
Device: /dev/ttyv?
NetBSD/arm32 specific problems:
On the RISCPC and RC7500 models the physical console driver
allows access from 0 to the base address of video memory.
These drivers must be associated with the system console and
the device nodes for these may not even exist.
Device: no default device.
NetBSD/mac68k specific problems:
The grf console driver allows access from 0 to the base address of
video memory. This driver must be associated with the system
console and is normally only exploitable to the user logged in on
the console. The Apple Sound Chip (asc) driver which provides
access to Apple Sound and console bell support may allow access to
page 0 to anyone. Both of these drivers may also cause
unpredictable system activity.
Devices: /dev/grf* & /dev/asc*
NetBSD/macppc (not available in NetBSD 1.3.2) specific problems:
The nvram d_mmap routine incorrectly returns EOPNOTSUPP instead
of -1 to indicate error, possibly causing the system to panic.
This is exploitable by anyone.
The ofb driver allows console users access to any memory location.
Devices: /dev/nvram and no default device for ofb.
NetBSD/sparc specific problems:
The cgeight and cgfour console drivers allow access from 0 to
the base address of video memory (0x500000), or may cause
unpredictable system activity. These drivers must be associated
with the system console and are normally only exploitable to the
user logged in on the console.
Devices: /dev/fb, /dev/cgfour* & /dev/cgeight*
NetBSD/vax specific problems:
The smg console driver may allow the console user access to memory
from 0 to 128KB and may cause the unpredictable system activity.
Note that this not a problem in NetBSD/vax 1.3.2.
Device: /dev/vt*
PCI device specific problems:
The tga console driver allow access from 0 to the base address of
video memory. This drivers must be associated with the system
console and is normally only exploitable to the user logged in on
the console.
Device: /dev/ttyE?
Turbo Channel (pmax & alpha) device specific problems:
The cfb, sfb, mfb and xcfb console drivers allow access from 0
to the base address of video memory, or may cause unpredictable
system activity. These drivers must be associated with the system
console and are normally only exploitable to the user logged in on
the console. Note that these devices are only available in the
TurboChannel Alpha models.
Device: /dev/fb? (pmax) & /dev/ttyE? (alpha)
Thanks To
- ---------
Many thanks to Chris G. Demetriou <cgd@NetBSD.ORG> and Ted Lemon
<mellon@NetBSD.ORG> for finding the original problem. Chris also
provided an initial investigation & analysis of the problem.
Matthew Green <mrg@eterna.com.au> found, analysed and fixed the
system as a whole. Tsubai Masanari <tsubai@NetBSD.ORG> provided
technical input for the NetBSD/macppc port and Kazuki Sakamoto
<sakamoto@NetBSD.ORG> provided technical input for the NetBSD/bebox
port.
More Information
- ----------------
Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.
Copyright 1998, The NetBSD Foundation, Inc. All Rights Reserved.
$NetBSD: NetBSD-SA1998-005.txt,v 1.3 1998/11/20 04:06:27 mrg Exp $
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNlTp7D5Ru2/4N2IFAQGVrAQApqIKBLZ+7xHpz7k1ZM5pD/WH66B5a1EI
B6Oj8u8De14GApHSwzv69Trh8b5NfztiIXbTn1JKHPrTNDuWsHP/Vox6HZkJ6G/F
Gf7Wb524zyeLZAARJB/z5G9NnsxESsckgldH+WHvcNrg/Osrt74EKaxr2tBh9+OT
9Hl6B2KWP2I=
=7Yke
-----END PGP SIGNATURE-----
--------------End of forwarded message-------------------------
---
Jeroen Ruigrok van der Werven/Asmodai
asmodai(at)wxs.nl | Cum angelis et pueris,
Junior Network/Security Specialist | fideles inveniamur
*BSD & picoBSD: The Power to Serve... <http://www.freebsd.org>;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.981120211151.asmodai>