Date: Wed, 6 Dec 2006 08:49:44 -0500 From: Bill Moran <wmoran@collaborativefusion.com> To: Colin Percival <cperciva@freebsd.org> Cc: freebsd security <freebsd-security@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem Message-ID: <20061206084944.cfeb39c2.wmoran@collaborativefusion.com> In-Reply-To: <45769654.5050307@freebsd.org> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to Colin Percival <cperciva@freebsd.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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061206084944.cfeb39c2.wmoran>