Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- From: Peter Pentchev <roam@xxxxxxxxxxx>
- Date: Wed, 6 Dec 2006 16:42:05 +0200
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@xxxxxxxxxxx roam@xxxxxxxx roam@xxxxxxxxxxx
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.
Attachment:
pgpR3gEFpGB4r.pgp
Description: PGP signature
- References:
- Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- From: Colin Percival
- Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- From: Josh Paetzel
- Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- From: Ruben de Groot
- Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- Prev by Date: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- Next by Date: Intel LAN Driver Buffer Overflow Local Privilege Escalation
- Previous by thread: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- Next by thread: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
- Index(es):
Relevant Pages
|
|