FreeBSD Security Advisory FreeBSD-SA-06:25.kmem

[Peter Pentchev]

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

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

-- 
Peter Pentchev	roam at ringlet.net    roam at cnsys.bg    roam at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20061206/fe662696/attachment.pgp