User: Password:
|
|
Subscribe / Log in / New account

A more useful metric

A more useful metric

Posted Sep 9, 2008 21:42 UTC (Tue) by spender (subscriber, #23067)
Parent article: Kernel security, year to date

It probably wouldn't raise much argument that over the past several years, the most serious and widely reported/recognized vulnerabilities have come out of isec.pl. A large reason for this is that they were one of the few groups that would actually publish exploit code. In a misguided view of security, many don't perceive there to be any "threat" unless a weaponized exploit is made public (clearly visible by continued mentions of the "vmsplice" boogey-man, for example).

So first some data (in chronological order):
http://isec.pl/vulnerabilities/0004.txt
http://isec.pl/vulnerabilities/isec-0012-do_brk.txt
http://isec.pl/vulnerabilities/isec-0012-mremap.txt
http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
http://isec.pl/vulnerabilities/isec-0015-msfilter.txt
http://isec.pl/vulnerabilities/isec-0016-procleaks.txt
http://isec.pl/vulnerabilities/isec-0017-binfmt_elf.txt
http://isec.pl/vulnerabilities/isec-0018-igmp.txt
http://isec.pl/vulnerabilities/isec-0019-scm.txt
http://isec.pl/vulnerabilities/isec-0022-pagefault.txt
http://isec.pl/vulnerabilities/isec-0023-coredump.txt
http://isec.pl/vulnerabilities/isec-0024-death-signal.txt
http://isec.pl/vulnerabilities/isec-0025-syscall-emulatio...
http://isec.pl/vulnerabilities/isec-0026-vmsplice_to_kern...

The last 3 and the first one are credited to Wojciech Purczynski (cliph@isec.pl), while the remaining 10 are credited to Paul Starzetz (ihaquer@isec.pl). The last 3 from cliph are during his employment at COSEINC.

Paul Starzetz had this to say about the Linux kernel (from http://searchenterpriselinux.techtarget.com/news/article/...):
"First the problem [with] Linux is that there are too many people 'hacking' the code. It has reached a complexity where the 'I-hack-quickly-some-code' approach doesn't work anymore."

and in reply to a security advisory dismissing one of his vulnerabilities as a "DoS" (from http://www.security-express.com/archives/bugtraq/2006-07/...):
"I really wonder why in the recent past there is a tendence to declare
such things as "denial of service" etc - while they are perfect root
backdoors / vulns

*B000M* you are in one minut^K^K^Ke later...

Maybe this is just to hide the overall bad quality of the 2.6 kernel
code? *just guessing*

Anyway CVE-2006-2451 is trivially exploitable so I don't attach any
exploit code since it is obvious..."

I should also mention that since October 15, 2007, Paul Starzetz has been employed by Immunity, who specifically practices non-disclosure. So if you're patting yourselves on the back because he hasn't made public any more serious exploits in the kernel, it has nothing to do with the quality of the code.

-Brad


(Log in to post comments)

A more useful metric

Posted Sep 9, 2008 21:47 UTC (Tue) by drag (subscriber, #31333) [Link]

> So if you're patting yourselves

Who are you talking to?

A more useful metric

Posted Sep 9, 2008 21:58 UTC (Tue) by sbishop (guest, #33061) [Link]

Those of us reading LWN...

So Spender isn't a writer; that's fine. But his comments provide enough content to justify content in return, I think.

A more useful metric

Posted Sep 9, 2008 23:13 UTC (Tue) by ballombe (subscriber, #9523) [Link]

That just a new fad on lwn comments: Meta-trolling.

Instead of trolling, accuse someone else of trolling! You get basically the same result but you have 'the moral high ground'(tm).

If you are lucky, people believe you were responding to a comment that have been deleted (!) and you can enjoy the ensuing confusion.

Maybe I am old fashioned, but I find trolls less painful than self righteous meta-trolls. (this post is intended as a meta-meta-troll).

A more useful metric

Posted Sep 9, 2008 23:50 UTC (Tue) by drag (subscriber, #31333) [Link]

Well thanks for the attention!

(weirdo)

A more useful metric

Posted Sep 10, 2008 0:15 UTC (Wed) by nix (subscriber, #2304) [Link]

I never meta-troll I didn't find annoying.

(sorry sorry)

A more useful metric

Posted Sep 10, 2008 5:01 UTC (Wed) by paulj (subscriber, #341) [Link]

He's assuming an audience for his comment, a sceptical or even hostile audience at that. It's a pretty obvious rhetorical device.

I despise myself slightly for adding to it, but do we really need to open a *second* sub-thread commenting on the style of spender's commenting? His posts are otherwise are very relevant and interesting, and the true audience here are surely intelligent enough to be able to sidestep the style issues...

A more useful metric

Posted Sep 10, 2008 6:31 UTC (Wed) by drag (subscriber, #31333) [Link]

Sure sure. All apologies.

A more useful metric

Posted Sep 10, 2008 9:05 UTC (Wed) by nix (subscriber, #2304) [Link]

His posts are very intelligent and interesting, but they lead to only two questions that I can see, one of which has been answered and the other of which may have no answer:

- can we fix the bugs? obviously yes, but then we get accused of cover-ups unless we raise the roof over every single bug: and see past posts from Al Viro about why it's ridiculously impractical to go via vendor-sec for every such bug: if major kernel developers refuse to use it because it's such an embargoing straitjacket, then castigating people because they don't use it is a waste of time.

- can we change things so that the bugs aren't introduced so fast? Maybe, but so far no method has been proposed that doesn't have the kernel developers recoiling in horror, and if a magic development method was known that avoided all security holes and didn't utterly devastate development rates, everyone would already be using it. (e.g. formal proving of absolutely everything from the spec on down reduces security holes, but is horrible for development. Multi-person review of every change, a-la OpenBSD, does the same, but a chronic lack of reviewers makes that hard: and areas like mm are sufficiently subtle that few people are qualified to be reviewers at all.)

Going back to even/odd doesn't strike me as being likely to happen, given that that system was imploding under the much lower change load that preceded git. A more rapidly alternating .26-is-stable .27-is-unstable scheme might work, but I'm not sure what that means other than giving a formal number to the post-merge-window -rc1 kernel, and I'm not sure how *that* would help. (It might encourage people to test the -rcs, I suppose!)

A more useful metric

Posted Sep 10, 2008 12:43 UTC (Wed) by jengelh (subscriber, #33263) [Link]

>"First the problem [with] Linux is that there are too many people 'hacking' the code. It has reached a complexity where the 'I-hack-quickly-some-code' approach doesn't work anymore."

Complexity... is only half of the story. LOC divided by complexity (unitless number, lower is better) is what you need to look at.

A more useful metric

Posted Sep 10, 2008 12:45 UTC (Wed) by jengelh (subscriber, #33263) [Link]

epic fail :)
Of course it should be complexity/LOC with lower-is-better.

A more useful metric

Posted Sep 10, 2008 18:32 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

The data you present here suggests that the problem was roughly of the same severity last year.

There is also the issue of the larger rate of change. The fact that more code gets into mainline is a basic requirement. The tools available today and the processes used today allow this.

If you don't allow the code to get into mainline, people will use bad, unreviewed out-of-tree code. Not to mention all sorts of bugs that will be added by distributions when attempting to integrate all sorts of patches.


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