[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#524373: marked as done (linux-2.6: /dev/mem rootkit vulnerability)

Your message dated Thu, 16 Apr 2009 23:50:54 -0600
with message-id <20090417055054.GE17944@lackof.org>
and subject line Re: Bug#524373: linux-2.6: /dev/mem rootkit vulnerability
has caused the Debian Bug report #524373,
regarding linux-2.6: /dev/mem rootkit vulnerability
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
524373: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524373
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
package: linux-2.6
severity: grave
tags: security

as seen in recent articles and discussions, the linux kernel is
currently vulnerable to rootkit attacks via the /dev/mem device.  one
article [1] mentions that there is an existing patch for the problem,
but does not link to it.  perhaps this fix can be found in the kernel
mailing lists.

[1]
http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=216500687

--- End Message ---
--- Begin Message --- 
Version: 2.6.29-1

On Thu, Apr 16, 2009 at 11:35:06PM -0400, Michael S. Gilbert wrote:
> reopen 524373
> thanks
>
> On Thu, 16 Apr 2009 16:53:38 -0400 Noah Meyerhans wrote:
> > On Thu, Apr 16, 2009 at 04:21:10PM -0400, Michael S. Gilbert wrote:
> > > 
> > > i think that any flaw that allows an attacker to elevate his pwnage from
> > > root to hidden should always be considered a grave security issue.
> > 
> > Your argument sounds like the one used by RIAA, MPAA etc, based on the
> > DMCA's anti-circumvention clause, to keep things like open source dvd
> > players illegal.  Just because something can be used for malicious
> > purposes, doesn't mean its existance is a bad thing.  There are reasons
> > for /dev/mem to exist, and why you might want to manipulate kernel state
> > through it.  Many of these do not involve rootkits.
> 
> this is a strawman argument.  i never said that /dev/mem needed to go
> away.  my point was that it needed to be secured against these newly
> discovered attacks, and it sounds like CONFIG_STRICT_DEVMEM does this.

As I said, this is turned on in sid.

> > The support for dynamically loadable kernel modules in Linux can be
> > abuses similarly.  Does that make it a "grave security issue"?
> 
> probably...at least until someone comes up with a secure way to do it.

Oh, come on.

grave
    makes the package in question unusable or mostly so, or causes
    data loss, or introduces a security hole allowing access to the
    accounts of users who use the package.

Is the kernel really unusable/insecure because a root user can do
something bad? Wouldn't that give every package a grave bug by
definition?

I certainly don't consider this issue invalid - and in fact, we have
taken action to resolve it for the next release - but please don't
blow it out of proportion.

> > But as Dann pointed out, we'll have CONFIG_STRICT_DEVMEM in the future
> > to help minimize exposure.
> 
> this is a very good thing, and i understand that it would cause a lot
> of hassle to backport this kind of change to stable since it could
> potentially break compatibility.  however, that doesn't mean that the
> issue shouldn't be tracked.  and it certainly doesn't mean that the bug
> should be closed.  i thought that one of debian's tenants was "we will
> not hide problems."

It has been tracked, and is now marked as resolved by version
2.6.29-1.

> > If you want to continue this discussion, I propose to do it outside the
> > BTS.
> 
> why?  isn't the bts a perfectly good place for discussion?
> 
> mike
> 
> 
> 

-- 
dann frazier

--- End Message ---
Reply to: