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--