|
|
Subscribe / Log in / New account

The x86_64 DOS hole

The x86_64 DOS hole

Posted Feb 4, 2010 15:14 UTC (Thu) by ortalo (guest, #4654)
Parent article: The x86_64 DOS hole

Contrast this story with the top level story of security page of this week.
Linux kernel developpers evidently demonstrate pretty high maturity with respect to security issues. (And it has been like this for nearly as long as I can remember...)
They also adhere to the general philosophy of public disclosure. (More precisely, no one among them has ever took action to prevent permanently the disclosure of a vulnerability. They fix it.)
Given such stories, all in all, I do not especially worry about my kernel being exploited to actually harm me. (I suspect you don't either, do you?)

So, to me, most of the additional effort that may be needed currently for security would be to find a way to convey this trust to the less knowledgeable users. To convey it *honestly* of course. They may be very grateful for this additional tranquility, don't you think?
And I like this idea of fighting in a frequently fear-driven field using peaceful assurance. (Should be devastating... ;-)

PS: One caveat with this process however, only average tranquility of the user base may improve. While appeasing the user base, we will probably spot empty holes in our own assurance statements. Most users certainly won't miss them but we may ourselves worry about them and end up sleeping a little less well than before.


to post comments

The x86_64 DOS hole

Posted Feb 4, 2010 16:46 UTC (Thu) by NAR (subscriber, #1313) [Link] (1 responses)

Linux kernel developpers evidently demonstrate pretty high maturity with respect to security issues. (And it has been like this for nearly as long as I can remember...)

You should read some of spender's comments here at LWN to get a slightly different view...

Given such stories, all in all, I do not especially worry about my kernel being exploited to actually harm me.

I don't know: problem first reported and missed on 15th December 2009, then again reported on 28 January 2010 - that's six weeks of head start for the black hats.

The x86_64 DOS hole

Posted Feb 4, 2010 18:35 UTC (Thu) by ortalo (guest, #4654) [Link]

Evidently, I do not see things from the same point of view as spender; while I do acknowledge the fact that the kernel may be more vulnerable than some think (and certainly the converse too).

6 weeks from first spot to correction for a DoS is not bad news from my point of view - that's precisely the point.

Furthermore, to show you that I am not simply of the angelic kind, 6 weeks is not an "honest" number. 6 weeks of vulnerability is over-optimistic, it does not take into account the time it will take for this correction to reach the standard Ubuntu kernel on my own computer.
It does not take into account the fact that some black hat (especially a "well-funded" one) may have spotted the vulnerability much earlier. (That's where there is often black magic at work in threat evaluation. But this parameter does exist, even though unobservable.)
It does not take into account the fact that several (how many btw?) distributed kernel versions may have the same flaw and that some of them have been deployed in the field and will never be corrected.

Let's be honest, even pessimistic. Especially as such time measurements are probably not very relevant. Anyway, we have a need for evaluation before adressing the evaluation result.

I am confident Linux will not compare unfavorably - first because I suspect few systems will dare try to stand the comparison. And even in this case it will be worth knowing that linux <=X.Y.Z cannot be used for specific security applications. (*If* competitors can prove to be better of course, and if users cannot wait for X.Y+1.Z... ;-)

The x86_64 DOS hole

Posted Feb 5, 2010 19:36 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> They also adhere to the general philosophy of public disclosure. (More
> precisely, no one among them has ever took action to prevent permanently
> the disclosure of a vulnerability. They fix it.)

can you provide a list of security fixes in the current stable tree (2.6.32.x) then? a whole world would be eternally grateful for that.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds