From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 09:33:34 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76ACE16A407; Wed, 6 Dec 2006 09:33:34 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2CA343CED; Wed, 6 Dec 2006 09:32:30 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (cperciva@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kB69XE8F083079; Wed, 6 Dec 2006 09:33:14 GMT (envelope-from security-advisories@freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kB69XElj083077; Wed, 6 Dec 2006 09:33:14 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 6 Dec 2006 09:33:14 GMT Message-Id: <200612060933.kB69XElj083077@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: security-advisories@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 09:33:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:25.kmem Security Advisory The FreeBSD Project Topic: Kernel memory disclosure in firewire(4) Category: core Module: sys_dev Announced: 2006-12-06 Credits: Rodrigo Rubira Branco Affects: All FreeBSD releases. Corrected: 2006-12-06 09:13:51 UTC (RELENG_6, 6.2-STABLE) 2006-12-06 09:14:23 UTC (RELENG_6_2, 6.2-RC2) 2006-12-06 09:14:59 UTC (RELENG_6_1, 6.1-RELEASE-p11) 2006-12-06 09:15:40 UTC (RELENG_6_0, 6.0-RELEASE-p16) 2006-12-06 09:16:17 UTC (RELENG_5, 5.5-STABLE) 2006-12-06 09:16:41 UTC (RELENG_5_5, 5.5-RELEASE-p9) 2006-12-06 09:17:09 UTC (RELENG_4, 4.11-STABLE) 2006-12-06 09:18:02 UTC (RELENG_4_11, 4.11-RELEASE-p26) CVE Name: CVE-2006-6013 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The firewire(4) driver provides support for IEEE 1394 ("FireWire") interfaces. This driver provides some of its functionality via the ioctl(2) system call. II. Problem Description In the FW_GCROM ioctl, a signed integer comparison is used instead of an unsigned integer comparison when computing the length of a buffer to be copied from the kernel into the calling application. III. Impact A user in the "operator" group can read the contents of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way; for example, a terminal buffer might include a user-entered password. IV. Workaround No workaround is available, but systems without IEEE 1394 ("FireWire") interfaces are not vulnerable. (Note that systems with IEEE 1394 interfaces are affected regardless of whether any devices are attached.) Note also that FreeBSD does not have any non-root users in the "operator" group by default; systems on which no users have been added to this group are therefore also not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE, 5-STABLE, or 6-STABLE, or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, or RELENG_4_11 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.11, 5.5, 6.0, and 6.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-06:25/kmem.patch # fetch http://security.FreeBSD.org/patches/SA-06:25/kmem.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/dev/firewire/fwdev.c 1.2.4.17 RELENG_4_11 src/UPDATING 1.73.2.91.2.27 src/sys/conf/newvers.sh 1.44.2.39.2.30 src/sys/dev/firewire/fwdev.c 1.2.4.16.4.1 RELENG_5 src/sys/dev/firewire/fwdev.c 1.44.2.2 RELENG_5_5 src/UPDATING 1.342.2.35.2.9 src/sys/conf/newvers.sh 1.62.2.21.2.11 src/sys/dev/firewire/fwdev.c 1.44.2.1.4.1 RELENG_6 src/sys/dev/firewire/fwdev.c 1.46.2.2 RELENG_6_2 src/UPDATING 1.416.2.29.2.1 src/sys/dev/firewire/fwdev.c 1.46.2.1.6.1 RELENG_6_1 src/UPDATING 1.416.2.22.2.13 src/sys/conf/newvers.sh 1.69.2.11.2.13 src/sys/dev/firewire/fwdev.c 1.46.2.1.4.1 RELENG_6_0 src/UPDATING 1.416.2.3.2.21 src/sys/conf/newvers.sh 1.69.2.8.2.17 src/sys/dev/firewire/fwdev.c 1.46.2.1.2.1 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6013 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-06:25.kmem.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFFdo1QFdaIBMps37IRAj4vAJ4vzhNk4MBkhAxsmeIAA0UgnXXOwACfY+Oe WhWIJLjTgqq+T3ZpySyRCNo= =FbZj -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 09:33:35 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8947A16A47B; Wed, 6 Dec 2006 09:33:35 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 730C443D5D; Wed, 6 Dec 2006 09:32:36 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (cperciva@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kB69XKxc083121; Wed, 6 Dec 2006 09:33:20 GMT (envelope-from security-advisories@freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kB69XKYe083119; Wed, 6 Dec 2006 09:33:20 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 6 Dec 2006 09:33:20 GMT Message-Id: <200612060933.kB69XKYe083119@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-06:26.gtar X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: security-advisories@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 09:33:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:26.gtar Security Advisory The FreeBSD Project Topic: gtar name mangling symlink vulnerability Category: contrib Module: contrib_tar Announced: 2006-12-06 Credits: Teemu Salmela Affects: FreeBSD 4.x and 5.x releases Corrected: 2006-12-06 09:16:17 UTC (RELENG_5, 5.5-STABLE) 2006-12-06 09:16:41 UTC (RELENG_5_5, 5.5-RELEASE-p9) 2006-12-06 09:17:09 UTC (RELENG_4, 4.11-STABLE) 2006-12-06 09:18:02 UTC (RELENG_4_11, 4.11-RELEASE-p26) CVE Name: CVE-2006-6097 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background GNU tar (gtar) is a utility to create and extract "tape archives", commonly known as tar files. GNU tar is included in FreeBSD 4.x as /usr/bin/tar, and in FreeBSD 5.x as /usr/bin/gtar. II. Problem Description Symlinks created using the "GNUTYPE_NAMES" tar extension can be absolute due to lack of proper sanity checks. III. Impact If an attacker can get a user to extract a specially crafted tar archive the attacker can overwrite arbitrary files with the permissions of the user running gtar. If file system permissions allow it, this may allow the attacker to overwrite important system file (if gtar is being run as root), or important user configuration files such as .tcshrc or .bashrc, which would allow the attacker to run arbitrary commands. IV. Workaround Use "bsdtar", which is the default tar implementation in FreeBSD 5.3 and higher. For FreeBSD 4.x, bsdtar is available in the FreeBSD Ports Collection as ports/archivers/libarchive. V. Solution NOTE: The solution described below causes GNU tar to exit with an error when handling an archive with GNUTYPE_NAMES entries. The FreeBSD Security Team does not consider this to be a significant regression, since GNUTYPE_NAMES has not been used for many years and is not supported by other archival software such as libarchive(3); but the original (insecure) behaviour can be retained by running GNU tar with the newly added --allow-name-mangling option. Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE, or 5-STABLE, or to the RELENG_5_5 or RELENG_4_11 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.11 and 5.5 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-06:26/gtar.patch # fetch http://security.FreeBSD.org/patches/SA-06:26/gtar.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/gnu/usr.bin/tar # make obj && make depend && make && make install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/contrib/tar/src/common.h 1.2.2.2 src/contrib/tar/src/extract.c 1.4.2.4 src/contrib/tar/src/tar.c 1.2.2.3 RELENG_4_11 src/UPDATING 1.73.2.91.2.27 src/sys/conf/newvers.sh 1.44.2.39.2.30 src/contrib/tar/src/common.h 1.2.2.1.10.1 src/contrib/tar/src/extract.c 1.4.2.3.8.1 src/contrib/tar/src/tar.c 1.2.2.2.6.1 RELENG_5 src/contrib/tar/src/common.h 1.2.10.1 src/contrib/tar/src/extract.c 1.6.8.1 src/contrib/tar/src/tar.c 1.3.4.1 RELENG_5_5 src/UPDATING 1.342.2.35.2.9 src/sys/conf/newvers.sh 1.62.2.21.2.11 src/contrib/tar/src/common.h 1.2.22.1 src/contrib/tar/src/extract.c 1.6.20.1 src/contrib/tar/src/tar.c 1.3.16.1 - ------------------------------------------------------------------------- VII. References http://marc.theaimsgroup.com/?l=full-disclosure&m=116414883029517 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6097 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-06:26.gtar.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFFdo1YFdaIBMps37IRAsqUAKCFRV7yICNP8NyC/3+uHUTOKDrxWQCeIJ5a HsY0N8aR6FoEiFYV/y5fO4k= =0/ws -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 11:10:46 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE53C16A403 for ; Wed, 6 Dec 2006 11:10:46 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd5mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F125A43CCB for ; Wed, 6 Dec 2006 11:09:50 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr4so.prod.shaw.ca (pd4mr4so-qfe3.prod.shaw.ca [10.0.141.215]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J9U003HVK4D4V90@l-daemon> for freebsd-security@freebsd.org; Wed, 06 Dec 2006 03:07:25 -0700 (MST) Received: from pn2ml3so.prod.shaw.ca ([10.0.121.147]) by pd4mr4so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9U00LFFK4C04G1@pd4mr4so.prod.shaw.ca> for freebsd-security@freebsd.org; Wed, 06 Dec 2006 03:07:25 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0J9U004J9K4CRWJ1@l-daemon> for freebsd-security@freebsd.org; Wed, 06 Dec 2006 03:07:24 -0700 (MST) Received: (qmail 3701 invoked from network); Wed, 06 Dec 2006 10:07:16 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Wed, 06 Dec 2006 10:07:16 +0000 Date: Wed, 06 Dec 2006 02:07:16 -0800 From: Colin Percival In-reply-to: <200612060933.kB69XErN083086@freefall.freebsd.org> To: freebsd security Message-id: <45769654.5050307@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 References: <200612060933.kB69XErN083086@freefall.freebsd.org> User-Agent: Thunderbird 1.5 (X11/20060416) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 11:10:47 -0000 FreeBSD Security Advisories wrote: > FreeBSD-SA-06:25.kmem Security Advisory > The FreeBSD Project > ... > III. Impact > > A user in the "operator" group can read the contents of kernel memory. > Such memory might contain sensitive information, such as portions of > the file cache or terminal buffers. This information might be directly > useful, or it might be leveraged to obtain elevated privileges in some > way; for example, a terminal buffer might include a user-entered > password. For what it's worth, there was a lot of debate about whether this deserved an advisory: Members of the operator group are allowed (by default, at least) to read raw disk devices, so being able to read kernel memory really isn't very much of a privilege escalation. In the end I decided to go ahead with this advisory largely because we were already planning on issuing an advisory this week (for a far more serious issue in GNU tar), but if a similar issue arises next month, we might decide not to bother with an advisory. I'd be interested to hear opinions from the FreeBSD community about whether this sort of issue is one which anyone really cares about. Colin Percival FreeBSD Security Officer From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 12:40:26 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C611516A5B4; Wed, 6 Dec 2006 12:40:26 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6784C44106; Wed, 6 Dec 2006 12:25:53 +0000 (GMT) (envelope-from josh@tcbug.org) Received: from gimpy (c-24-118-173-219.hsd1.mn.comcast.net[24.118.173.219]) by comcast.net (sccrmhc13) with ESMTP id <2006120612263201300lq3dme>; Wed, 6 Dec 2006 12:26:32 +0000 From: Josh Paetzel To: freebsd-security@freebsd.org Date: Wed, 6 Dec 2006 06:26:31 -0600 User-Agent: KMail/1.9.4 References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> In-Reply-To: <45769654.5050307@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612060626.31834.josh@tcbug.org> Cc: Colin Percival Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 12:40:26 -0000 On Wednesday 06 December 2006 04:07, Colin Percival wrote: > FreeBSD Security Advisories wrote: > > FreeBSD-SA-06:25.kmem > > Security Advisory The FreeBSD Project ... > > III. Impact > > > > A user in the "operator" group can read the contents of kernel > > memory. Such memory might contain sensitive information, such as > > portions of the file cache or terminal buffers. This information > > might be directly useful, or it might be leveraged to obtain > > elevated privileges in some way; for example, a terminal buffer > > might include a user-entered password. > > For what it's worth, there was a lot of debate about whether this > deserved an advisory: Members of the operator group are allowed (by > default, at least) to read raw disk devices, so being able to read > kernel memory really isn't very much of a privilege escalation. In > the end I decided to go ahead with this advisory largely because we > were already planning on issuing an advisory this week (for a far > more serious issue in GNU tar), but if a similar issue arises next > month, we might decide not to bother with an advisory. > > I'd be interested to hear opinions from the FreeBSD community about > whether this sort of issue is one which anyone really cares about. > > Colin Percival > FreeBSD Security Officer Sure, and if you can read raw disk devices you can read /etc/master.passwd and /etc/group....and if you can do that then it's trivial to break the passwords you need to su to someone in wheel and then su to root. I guess my point is someone in the operator group has a far easier way to gain root than this vuln. It's great to fix bugs, but I bet this one won't prompt many people to apply the patches and/or rebuild world to fix. Damned if you do, damned if you don't. If you don't issue an SA then people mumble about how FBSD ignores security issues. If you do issue the SA then people mumble about how pointless this one was. My opinion is I'd rather know about it and make the decision myself whether to apply the fixes than not know about it at all. -- Thanks, Josh Paetzel From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 13:43:29 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A2FA16A417; Wed, 6 Dec 2006 13:43:29 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (ei.xs4all.nl [213.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFDB443CC2; Wed, 6 Dec 2006 13:42:36 +0000 (GMT) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.13.8/8.13.8) with ESMTP id kB6Dh3DD066254; Wed, 6 Dec 2006 14:43:03 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.13.8/8.13.8/Submit) id kB6Dh32d066253; Wed, 6 Dec 2006 14:43:03 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 6 Dec 2006 14:43:03 +0100 From: Ruben de Groot To: Josh Paetzel Message-ID: <20061206134303.GA63129@ei.bzerk.org> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> <200612060626.31834.josh@tcbug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612060626.31834.josh@tcbug.org> User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (ei.bzerk.org [127.0.0.1]); Wed, 06 Dec 2006 14:43:04 +0100 (CET) X-Mailman-Approved-At: Wed, 06 Dec 2006 13:45:34 +0000 Cc: freebsd-security@freebsd.org, Colin Percival Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 13:43:29 -0000 On Wed, Dec 06, 2006 at 06:26:31AM -0600, Josh Paetzel typed: > On Wednesday 06 December 2006 04:07, Colin Percival wrote: > > FreeBSD Security Advisories wrote: > > > FreeBSD-SA-06:25.kmem > > > Security Advisory The FreeBSD Project ... > > > III. Impact > > > > > > A user in the "operator" group can read the contents of kernel > > > memory. Such memory might contain sensitive information, such as > > > portions of the file cache or terminal buffers. This information > > > might be directly useful, or it might be leveraged to obtain > > > elevated privileges in some way; for example, a terminal buffer > > > might include a user-entered password. > > > > For what it's worth, there was a lot of debate about whether this > > deserved an advisory: Members of the operator group are allowed (by > > default, at least) to read raw disk devices, so being able to read > > kernel memory really isn't very much of a privilege escalation. In > > the end I decided to go ahead with this advisory largely because we > > were already planning on issuing an advisory this week (for a far > > more serious issue in GNU tar), but if a similar issue arises next > > month, we might decide not to bother with an advisory. > > > > I'd be interested to hear opinions from the FreeBSD community about > > whether this sort of issue is one which anyone really cares about. > > > > Colin Percival > > FreeBSD Security Officer > > Sure, and if you can read raw disk devices you can > read /etc/master.passwd and /etc/group....and if you can do that then > it's trivial to break the passwords you need to su to someone in > wheel and then su to root. > > I guess my point is someone in the operator group has a far easier way > to gain root than this vuln. True, but only in the default configuration. The reading of raw disk devices really is controlled by filesystem privileges: # ls -l /dev/ad4 crw-r----- 1 root operator 0, 84 Dec 6 08:50 /dev/ad4 So you could for example remove the read bit for operators on some devices, while still allowing them to dump/backup some other specific devices. This isn't the case for kmem: # ls -l /dev/kmem crw-r----- 1 root kmem 0, 25 Dec 6 08:50 /dev/kmem In my opinion that makes this a bug and a security issue. Ruben de Groot From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 13:49:46 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE2AB16A415; Wed, 6 Dec 2006 13:49:46 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6900143CA7; Wed, 6 Dec 2006 13:49:00 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 06 Dec 2006 08:49:45 -0500 id 0005642E.4576CA79.000034B6 Date: Wed, 6 Dec 2006 08:49:44 -0500 From: Bill Moran To: Colin Percival Message-Id: <20061206084944.cfeb39c2.wmoran@collaborativefusion.com> In-Reply-To: <45769654.5050307@freebsd.org> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd security Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 13:49:47 -0000 In response to Colin Percival : > FreeBSD Security Advisories wrote: > > FreeBSD-SA-06:25.kmem Security Advisory > > The FreeBSD Project > > ... > > III. Impact > > > > A user in the "operator" group can read the contents of kernel memory. > > Such memory might contain sensitive information, such as portions of > > the file cache or terminal buffers. This information might be directly > > useful, or it might be leveraged to obtain elevated privileges in some > > way; for example, a terminal buffer might include a user-entered > > password. > > For what it's worth, there was a lot of debate about whether this deserved > an advisory: Members of the operator group are allowed (by default, at least) > to read raw disk devices, so being able to read kernel memory really isn't > very much of a privilege escalation. In the end I decided to go ahead with > this advisory largely because we were already planning on issuing an advisory > this week (for a far more serious issue in GNU tar), but if a similar issue > arises next month, we might decide not to bother with an advisory. > > I'd be interested to hear opinions from the FreeBSD community about whether > this sort of issue is one which anyone really cares about. It seems as if something is shifting in the world. There seem to be a lot more sources of "security advisories" now than just a few years ago, and some of them pretty sketch as far as how much I trust them. It seems as if there's some marketing potential to claiming that your company was the first to find a security problem, which means some folks are willing to announce "security problems" even when they aren't, because their marketing department sees value in it. To follow that prelude, perhaps it would be worthwhile to have a separate type of mailing -- "security-related bugs" or some such, that lists bugs and other issues that have security implications but the FreeBSD team doesn't quite see as as a security flaw. That firewire thing is a strong candidate, and there have been a few others come up over the last few weeks. This would allow folks who trip across "Jonny-come-lately-security-company finds a serious bug in the FreeBSD kernel" advisories to have a place on the FreeBSD web site to see an official explanation of why the FreeBSD team does not see said bug as a security concern. I figure, that by the time the sec team has determined that it doesn't warrant an advisory, they've already done enough work that they can easily publish a quick explanation of why it isn't -- but I've never worked with the security team, so I could be misjudging. Just some brainstorming. -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 14:14:42 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C316616A415; Wed, 6 Dec 2006 14:14:42 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F79943CAD; Wed, 6 Dec 2006 14:13:53 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id F050346DA5; Wed, 6 Dec 2006 15:14:37 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1D487487FF; Wed, 6 Dec 2006 15:14:32 +0100 (CET) Date: Wed, 6 Dec 2006 15:14:21 +0100 From: Pawel Jakub Dawidek To: Colin Percival Message-ID: <20061206141421.GF5236@garage.freebsd.pl> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o71xDhNo7p97+qVi" Content-Disposition: inline In-Reply-To: <45769654.5050307@freebsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd security Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 14:14:42 -0000 --o71xDhNo7p97+qVi Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 06, 2006 at 02:07:16AM -0800, Colin Percival wrote: > FreeBSD Security Advisories wrote: > > FreeBSD-SA-06:25.kmem Security Ad= visory > > The FreeBSD P= roject > > ... > > III. Impact > >=20 > > A user in the "operator" group can read the contents of kernel memory. > > Such memory might contain sensitive information, such as portions of > > the file cache or terminal buffers. This information might be directly > > useful, or it might be leveraged to obtain elevated privileges in some > > way; for example, a terminal buffer might include a user-entered > > password. >=20 > For what it's worth, there was a lot of debate about whether this deserved > an advisory: Members of the operator group are allowed (by default, at le= ast) > to read raw disk devices, so being able to read kernel memory really isn't > very much of a privilege escalation. [...] Definitely. There always could be a kernel dump on a swap device. I really see no point at all in such security advisories. Local DoSes are much more important and we don't publish security advisories for them, because as we all well know there are many, many such bugs in any operating system out there and will be just silly to publishing security advisory for every single local DoS. > [...] In the end I decided to go ahead with > this advisory largely because we were already planning on issuing an advi= sory > this week (for a far more serious issue in GNU tar), but if a similar iss= ue > arises next month, we might decide not to bother with an advisory. That's why IMHO it was a mistake to publish this one, because people can start depend on the fact that we publish security advisories for such bugs. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --o71xDhNo7p97+qVi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFdtA9ForvXbEpPzQRAle9AKC7JO4bCuKTMKFgGtbJ4vtTqU+uAgCgoKGQ SKiiT2L+4tC3m6xh35fdWjE= =2nUF -----END PGP SIGNATURE----- --o71xDhNo7p97+qVi-- From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 14:42:04 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA63A16A415 for ; Wed, 6 Dec 2006 14:42:03 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from straylight.ringlet.net (nat102.cnsys.bg [85.95.80.102]) by mx1.FreeBSD.org (Postfix) with SMTP id 3013943CC2 for ; Wed, 6 Dec 2006 14:41:07 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 90546 invoked by uid 1000); 6 Dec 2006 14:42:05 -0000 Date: Wed, 6 Dec 2006 16:42:05 +0200 From: Peter Pentchev To: Ruben de Groot Message-ID: <20061206144205.GA1820@straylight.m.ringlet.net> Mail-Followup-To: Ruben de Groot , Josh Paetzel , freebsd-security@freebsd.org, Colin Percival References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> <200612060626.31834.josh@tcbug.org> <20061206134303.GA63129@ei.bzerk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20061206134303.GA63129@ei.bzerk.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Josh Paetzel , Colin Percival , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 14:42:04 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 06, 2006 at 02:43:03PM +0100, Ruben de Groot wrote: > On Wed, Dec 06, 2006 at 06:26:31AM -0600, Josh Paetzel typed: > > On Wednesday 06 December 2006 04:07, Colin Percival wrote: > > > FreeBSD Security Advisories wrote: > > > > FreeBSD-SA-06:25.kmem =20 > > > > Security Advisory The FreeBSD Project ... > > > > III. Impact > > > > > > > > A user in the "operator" group can read the contents of kernel > > > > memory. Such memory might contain sensitive information, such as > > > > portions of the file cache or terminal buffers. This information > > > > might be directly useful, or it might be leveraged to obtain > > > > elevated privileges in some way; for example, a terminal buffer > > > > might include a user-entered password. > > > > > > For what it's worth, there was a lot of debate about whether this > > > deserved an advisory: Members of the operator group are allowed (by > > > default, at least) to read raw disk devices, so being able to read > > > kernel memory really isn't very much of a privilege escalation. In > > > the end I decided to go ahead with this advisory largely because we > > > were already planning on issuing an advisory this week (for a far > > > more serious issue in GNU tar), but if a similar issue arises next > > > month, we might decide not to bother with an advisory. > > > > > > I'd be interested to hear opinions from the FreeBSD community about > > > whether this sort of issue is one which anyone really cares about. > > > > > > Colin Percival > > > FreeBSD Security Officer > >=20 > > Sure, and if you can read raw disk devices you can=20 > > read /etc/master.passwd and /etc/group....and if you can do that then= =20 > > it's trivial to break the passwords you need to su to someone in=20 > > wheel and then su to root. > >=20 > > I guess my point is someone in the operator group has a far easier way= =20 > > to gain root than this vuln. >=20 > True, but only in the default configuration. The reading of raw disk > devices really is controlled by filesystem privileges: >=20 > # ls -l /dev/ad4 > crw-r----- 1 root operator 0, 84 Dec 6 08:50 /dev/ad4 >=20 > So you could for example remove the read bit for operators on some device= s, > while still allowing them to dump/backup some other specific devices. >=20 > This isn't the case for kmem: >=20 > # ls -l /dev/kmem > crw-r----- 1 root kmem 0, 25 Dec 6 08:50 /dev/kmem >=20 > In my opinion that makes this a bug and a security issue. Ehh... but from what I gather, the point of this security advisory is that users in the "operator" (not "kmem") group can access the /dev/fwN and /dev/fwmemN devices, and thus do Bad Things(tm) to the kernel. Soooo - the "only in the default configuration" qualification applies just as much to the FireWire devices as to the raw disk ones - both may be controlled by filesystem privileges. Unless I've really misunderstood what you were saying, of course :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence every third, but it still comprehensible. --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFdta97Ri2jRYZRVMRAr/CAJ4wbhy/unim8z0a8kX48fAp/AQyPQCgnwaC +rhF7WX8CihKIKcbTMtsuoc= =cxRW -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 15:42:50 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA2716A403 for ; Wed, 6 Dec 2006 15:42:50 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [217.13.206.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82B1D43CBD for ; Wed, 6 Dec 2006 15:42:03 +0000 (GMT) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 12883 invoked from network); 6 Dec 2006 15:42:47 -0000 Received: from unknown (HELO ?10.1.1.245?) (cryx@62.220.7.20) by mail.h3q.com with AES256-SHA encrypted SMTP; 6 Dec 2006 15:42:47 -0000 Message-ID: <4576E4F9.4070308@h3q.com> Date: Wed, 06 Dec 2006 16:42:49 +0100 From: Philipp Wuensche User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Intel LAN Driver Buffer Overflow Local Privilege Escalation X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 15:42:50 -0000 Hi, I found an advisory (http://www.intel.com/support/network/sb/CS-023726.htm) from intel for their LAN driver for the eepro100 and gigabit network cards. Is the FreeBSD em driver in any way affected by this problem? Looks like it is at least derived from the intel driver. greetings, philipp wuensche From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 16:46:28 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EAB316A4A0; Wed, 6 Dec 2006 16:46:28 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B339643DAA; Wed, 6 Dec 2006 16:45:04 +0000 (GMT) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from [10.11.0.2] (kulesh.obluda.cz [213.29.48.25]) by smtp1.kolej.mff.cuni.cz (8.13.6/8.13.6) with ESMTP id kB6GjafT007304; Wed, 6 Dec 2006 17:45:38 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <4576F3A9.9000307@obluda.cz> Date: Wed, 06 Dec 2006 17:45:29 +0100 From: Dan Lukes Organization: Obludarium User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> In-Reply-To: <45769654.5050307@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Colin Percival Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 16:46:28 -0000 Colin Percival napsal/wrote: >> A user in the "operator" group can read the contents of kernel memory. >> Such memory might contain sensitive information, such as portions of >> the file cache or terminal buffers. This information might be directly >> useful, or it might be leveraged to obtain elevated privileges in some >> way; for example, a terminal buffer might include a user-entered >> password. > > For what it's worth, there was a lot of debate about whether this deserved > an advisory: Members of the operator group are allowed (by default, at least) > to read raw disk devices, so being able to read kernel memory really isn't > very much of a privilege escalation. Even if the user with (unwanted) access memory has the read access to raw disk device we can't assume that all private data presend in memory are present on disk also. Especially when swap disabled. Paranoid application allocate non-swappable memory to store critical data also. There may be in-memory decrypted data (password supplied by user) that are never present on disk in raw form. Also, the PAM allow to configure the computer to authenticate users without passwords in master.passwd - but the correct and usable password still can be found in memory during authentication phase. Unless we can safelly assume that an user can't use the bug to acces data that isn't accesible via other interface, then we found new data channel. If we founded a new data channel where it should not be, then we found a point of possible data leakage. If data leak to someone who should not have acces to it, we found the security bug. There - someone has unwanted access to memory. It's security bug. The fact the user has the regular read-only access to raw disk device is irelevant unless all data avaiable in memory are avaiable on disk also. > I'd be interested to hear opinions from the FreeBSD community about whether > this sort of issue is one which anyone really cares about. Despite the fact that this bug don't create real security violation on any system under my supervision, I would like to know all informations that *may* affect security of a system. Including those you are not sure they really affect security or not. I'm administrator of system, I'm responsible for it's security, I will make final decision. I will ignore those information that doesn't claim security problem on my systems (but it still may claim security problem on other's system). Informations doesn't hurt. The lack of information may hurt. Dan From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 18:11:28 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2736F16A4C8; Wed, 6 Dec 2006 18:11:28 +0000 (UTC) (envelope-from brain@winbot.co.uk) Received: from brainbox.winbot.co.uk (cpc1-mapp3-0-0-cust243.nott.cable.ntl.com [82.20.212.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACD0243D92; Wed, 6 Dec 2006 18:09:09 +0000 (GMT) (envelope-from brain@winbot.co.uk) Received: from synapse.brainbox.winbot.co.uk ([10.0.0.2] helo=[192.168.1.10]) by brainbox.winbot.co.uk with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Gs16F-0006cl-2S; Wed, 06 Dec 2006 18:02:31 +0000 Message-ID: <4577076A.6080508@winbot.co.uk> Date: Wed, 06 Dec 2006 18:09:46 +0000 From: Craig Edwards Organization: Crypt Software User-Agent: Thunderbird 1.5.0.7 (X11/20061001) MIME-Version: 1.0 To: Dan Lukes References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> <4576F3A9.9000307@obluda.cz> In-Reply-To: <4576F3A9.9000307@obluda.cz> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, Colin Percival Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: brain@winbot.co.uk List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 18:11:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doesn't securelevel completely mitigate this even for root users anyway, if set? Setting securelevel denies raw access to disk devices and kmem in this way does it not? - -- Craig Edwards Dan Lukes wrote: > Colin Percival napsal/wrote: >>> A user in the "operator" group can read the contents of kernel memory. >>> Such memory might contain sensitive information, such as portions of >>> the file cache or terminal buffers. This information might be directly >>> useful, or it might be leveraged to obtain elevated privileges in some >>> way; for example, a terminal buffer might include a user-entered >>> password. - -- OpenPGP Key ID: 0x49B959F7 "Better to reign in Hell than to serve in Heaven" -- Milton -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdwdqCd57Ikm5WfcRAmx9AKDCtIqEj5lREwepRoFfcnMJNGwixQCfQ3WI c34CNp+R5Zsgl/PyE32Qr0c= =lRB+ -----END PGP SIGNATURE-----