Date: Wed, 6 Dec 2006 14:43:03 +0100 From: Ruben de Groot <mail25@bzerk.org> To: Josh Paetzel <josh@tcbug.org> Cc: freebsd-security@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem Message-ID: <20061206134303.GA63129@ei.bzerk.org> In-Reply-To: <200612060626.31834.josh@tcbug.org> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> <200612060626.31834.josh@tcbug.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061206134303.GA63129>