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

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
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

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

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

In response to Colin Percival <cpercivafreebsd.org>:

> 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.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Wed, Dec 06, 2006 at 02:07:16AM -0800, 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. [...]

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

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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjdFreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I
Am!

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	roamringlet.net    roamcnsys.bg    roamFreeBSD.org
PGP key:	http://p
eople.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.

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

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

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


iD8DBQFFdwdqCd57Ikm5WfcRAmx9AKDCtIqEj5lREwepRoFfcnMJNGwixQCf
Q3WI
c34CNp+R5Zsgl/PyE32Qr0c=
=lRB+
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Wed, 6 Dec 2006, Craig Edwards wrote:

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

Securelevel is intended to protect integrity and not
confidentiality, so does 
not prevent reading, not writing, so is unrelated to this
specific issue.

I come out generally against releasing an advisory for this
issue.  In the 
current security model, members of the operator group have a
high level of 
privilege in the system, as they can:

- Read from partitions used for file system storage,
including delete and
  unallocated space.

- Read from swap partitions, allowing access to both kernel
dumps and paged
   out process data.  Since they can generally force paging
on systems with
   swap, this effectively means read access to most process
memory, as well as
   the pageable memory associated with kernel pipe IPC.

- Directly interface with the many controllers and other
devices via device
   drivers granting read or write access to the operator
group.

I think releasing a security advisory for this problem
offers a false promise: 
we don't promise to protect kernel data or the kernel from
the operator user, 
and releasing an advisory suggests we do.  I think it's very
likely that other 
device drivers

On the other hand, I think we should be thinking about
replacements for our 
current notion of an operator group.  For example, should we
have 
shutdown/dump/etc be setgid operator for access to disk, but
authorize use 
based on membership of another group, which would avoid
granting device I/O 
privileges to members of this new operator group?  Likewise,
the right to 
shutdown a system should not necessarily correspond with the
right to back up 
any mounted file system.  Thoughts on the best thing to do
here would be most 
welcome.

Mac OS X, for example, has a notion of a user space policy
file in /etc that 
is checked by various setuid/setgid tools to see whether the
invoking user has 
a specific high level privilege.  The distinction between
high level and low 
level there, btw, is that a low level privilege is the
privilege as 
represented with respect to the kernel (reboot, read raw
disk, etc) and the 
high level privilege is the use of privilege provided and
interpretted by a 
privilege-elevated (setuid/setgid) program (the right to
shutdown, the right 
to back up, etc).  Obviously, the program implementing the
service has to have 
significant low level privilege, but it also gates rights
due to its 
interpretation of a higher level notion of privilege and
authorization.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"