A /proc/PID/mem vulnerability

Posted Jan 26, 2012 7:07 UTC (Thu) by kurtseifried (guest, #57307)
Parent article: A /proc/PID/mem vulnerability

So I emailed this in and had an email conversation with Jake, but apparently it is not possible to amend the story to include updates/factual corrections (and Jake suggested I post this as a comment):

-----

Your article has a major error (well several but this is one of the
biggest):

"The first indication that other distributions had was likely from Red
Hat's Eugene Teo's request for a CVE on the oss-security mailing list."

Sigh. No. This issue was discussed on the vendor sec list (a list
specifically created for Linux distribution security people so they can
notify each other of embargoed issues and co-ordinate things, share
fixes, workarounds, etc.) and all the main Linux distributions (well
anyone that cares enough about security to have a security person sign
up for the vendor-sec list) knew about this issue in advance of the
public CVE request to OSS-sec.

For more information on the closed list please see:

http://seclists.org/oss-sec/2011/q2/4

if you go through the archives (look for subject line "Closed list" or
"Re: Closed list" and you'll find pretty much every major Linux vendor
is on there.

Kurt Seifried / Red Hat Security Response team

A /proc/PID/mem vulnerability

Posted Jan 26, 2012 8:53 UTC (Thu) by danielpf (guest, #4723) [Link] (2 responses)

Between Torvald's attitude to not elaborate on security bugs and the security expert attitude to fully explain the bugs rather sooner than later, an intermediate attitude should be to comment security bugs gradually in depth once the patches have been applied to a reasonable fraction of users. LWN editorials do a great contribution in this direction. Not commenting bugs prevent developers to learn on the long term, and commenting bugs too early damages Linux security reputation.

A /proc/PID/mem vulnerability

Posted Jan 31, 2012 5:45 UTC (Tue) by malor (guest, #2973) [Link]

and commenting bugs too early damages Linux security reputation.

A better summation would be tells the truth, and we can't have users knowing the TRUTH, because they might not use Linux.

Much, much better to lie to them, to get users to use your code.

Well, better for you, anyway.

A /proc/PID/mem vulnerability

Posted Jan 31, 2012 5:48 UTC (Tue) by malor (guest, #2973) [Link]

I mean, that's the Catholic Church approach to computer security -- the reputation of the ~~church~~ kernel is much, more more important than protecting ~~children~~ users.

A /proc/PID/mem vulnerability

Posted Jan 26, 2012 11:24 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> Your article has a major error [...]

does it? let's see the timeline:

1. original bugreport: Tue, 17 Jan 2012 07:38:51 +0200
2. Linus' commit: Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)
3. Eugene's mail on oss-sec: Wed, 18 Jan 2012 10:25:55 +0800
4. CVE assigned by Kurt: Tue, 17 Jan 2012 19:30:33 -0700
5. Red Hat bugzilla #782681: 2012-01-18 02:09:22 EST
6. Fedora fix by Josh Boyer: Wed, 18 Jan 2012 15:08:53 +0000 (10:08 -0500)
7. Kees' mail on oss-sec: Wed, 18 Jan 2012 12:43:28 -0800
8. Kees' mail on the 'secret' vendor list: Thu, 19 Jan 2012 00:06:50 -0800

you're saying that something else happened between 2 and 3 on linux-distros? evidence wants to be seen! i'm also wondering how Eugene had gotten wind of the security related impact of the commit before anyone else did.