LWN.net Logo

A nasty local kernel vulnerability

Over the weekend, the networking tree accepted a fix for an out-of-bounds access error that appears to be exploitable by an unprivileged local user to gain root access. Even worse, there are indications that this bug (which affects kernels from 3.3 onward) has been known about since mid-2012; exploits exist in the wild. No distributor updates exist as of this writing; presumably they will not be long in coming.

[Update February 27: Distributions have started putting out updates for the vulnerability.]


(Log in to post comments)

A nasty local kernel vulnerability

Posted Feb 25, 2013 22:47 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

On Fedora 18 (with SELinux turned on), I was unable to get the code to pop a root shell with the exploit code posted.

A nasty local kernel vulnerability

Posted Feb 26, 2013 0:08 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

to quote a classic: "Just use a supported kernel"

A nasty local kernel vulnerability

Posted Feb 26, 2013 12:00 UTC (Tue) by dpquigl (subscriber, #52852) [Link]

Its kinda disappointing that the POC doesn't support arbitrary kernels above 3.3. Usually when Spender releases a POC he manages to get it working generically on multiple kernels so someone has shown it possible. Is there something specific about this exploit that makes it that he only supports 3 of the distro kernels?

A nasty local kernel vulnerability

Posted Feb 26, 2013 12:29 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

> Is there something specific about this exploit that makes it that he only supports 3 of the distro kernels?

i guess you didn't read the README either :P

> mpougatsa_me_krema_kai_milko.tgz -- A trimmed down version of an old exploit for
> the recently published `sock_diag_handlers[]' vulnerability :(

or the code:

/* ...just in case you forgot the root password on your Fedora CPanel/Plesk ;) */
static struct target targets[] = {
/* ... */
{"Fedora Core 17 3.4.4-3.fc17.i686 #1", 57, VOIDP(0xc045bb50), VOIDP(0xc045b8e0)},
{"Fedora Core 17 3.5.2-3.fc17.i686 #1", 57, VOIDP(0xc045ec60), VOIDP(0xc045ea20)},
{"Fedora Core 17 3.5.5-2.fc17.i686 #1", 57, VOIDP(0xc045ed60), VOIDP(0xc045eb20)}
/* ... */
};

extra brownie points if you can find the right numbers for your kernel ;).

A nasty local kernel vulnerability

Posted Feb 26, 2013 12:45 UTC (Tue) by dowdle (subscriber, #659) [Link]

It isn't called Fedora Core anymore. Just Fedora. Yeah, this probably isn't the right place for this but...

A nasty local kernel vulnerability

Posted Feb 26, 2013 19:20 UTC (Tue) by dpquigl (subscriber, #52852) [Link]

So basically it was just made lame instead of detecting the addresses on its own. So if you took Brad's symbol location code from his released exploits and popped them into this you wouldn't need the kernel signatures as long as a system.map or kallsyms was detected.

A nasty local kernel vulnerability

Posted Feb 26, 2013 21:53 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

exactly. try to convince him to update enlightenment that hasn't seen one in a while as this bug's like the perfect candidate :).

A nasty local kernel vulnerability

Posted Feb 27, 2013 19:47 UTC (Wed) by dpquigl (subscriber, #52852) [Link]

For those who want to try out the exploit on a vm or something You can add a line similar to this into that targets array in main.c.

{"My Kernel", 57, VOIDP(<addr of perpare_kernel_cred>), VOIDP(<addr of commit_creds>)}

I haven't read through the entire exploit so the 57 may need to be changed to something else but it might not need to be since it stays the same across kernel versions.

Also to get the addresses of prepare_kernel_cred and commit_creds just grep those symbols in your System.map under boot. Example: grep prepare_kernel_cred /boot/System.map.mykernel

Assuming the code in shellcode.c is the only shellcode being used (which once again I haven't read it all) it appears to change the creds structure of the running process. It does this by calling the function pointer they have to perpare_kernel_cred (kernel/cred.c) with NULL which will use the init cred which has a UID and GID of 0. It then uses the commit_creds function pointer it has with the new root creds structure to set the creds of the process to root.

I'm not about to run the exploit on my work machine so I'm not sure if the line I gave above will work 100% but its a start. This is what PaXTeam was getting at with his response to the other guy claiming you're safe if the exploit didn't print out a certain message. The exploitable bug may still be in your kernel. The issue is that the two magic numbers for function addresses weren't right. BTW you have the potential of kernel oopsing your box if you run the exploit with bad addresses and you happen to hit pages you shouldn't be touching.

This is the difference between an exploitable bug and a weaponized exploit. The bug is still there and just because this implementation/POC didn't work on your machine doesn't mean you're not vulnerable. PaXTeam and Brad may be harsh with their words but this is a very important point to get. Just because this example didn't work on your box doesn't mean you're not vulnerable. This could have just as easily have been written to scan kallsyms or a system.map based on information from uname to pull those addresses and work.

A nasty local kernel vulnerability

Posted Feb 26, 2013 0:19 UTC (Tue) by bojan (subscriber, #14302) [Link]

A nasty local kernel vulnerability

Posted Feb 26, 2013 0:35 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Hmm, I'm running 3.7.9-201, so I, presumably, don't have the fix running.

A nasty local kernel vulnerability

Posted Feb 26, 2013 0:36 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Actually, that's the laptop. The desktop (where I tested it) is running 3.7.6-201.

A nasty local kernel vulnerability

Posted Feb 26, 2013 10:44 UTC (Tue) by smokeing (guest, #53685) [Link]

Maybe not relevant, but here's what I have on my Gentoo box:

hmmr@ke:~/D/incoming/mpougatsa_me_krema_kai_milko] make
cc -Wall -Wno-unused-result -std=gnu99 -O2 -ggdb -c -o vmsuck.o vmsuck.c
cc -Wall -Wno-unused-result -std=gnu99 -O2 -ggdb -c -o trigger.o trigger.c
cc -Wall -Wno-unused-result -std=gnu99 -O2 -ggdb -c -o shellcode.o shellcode.c
cc -Wall -Wno-unused-result -std=gnu99 -O2 -ggdb -c -o main.o main.c
cc vmsuck.o trigger.o shellcode.o main.o -o woopme -lm
hmmr@ke:~/D/incoming/mpougatsa_me_krema_kai_milko] ./woopme

Linux kernel >= 3.2 NETLINK_INET_DIAG 0day
by huku <huku _at_ grhack _dot_ net>

Available targets:
00 Fedora Core 17 3.4.4-3.fc17.i686 #1
01 Fedora Core 17 3.5.2-3.fc17.i686 #1
02 Fedora Core 17 3.5.5-2.fc17.i686 #1

hmmr@ke:~/D/incoming/mpougatsa_me_krema_kai_milko] ./woopme 1

Linux kernel >= 3.2 NETLINK_INET_DIAG 0day
by huku <huku _at_ grhack _dot_ net>

Using target "Fedora Core 17 3.5.2-3.fc17.i686 #1"
Current uid is 1000
Sucking up the whole VM space
Creating 1G file...100.00%
70340826890240b 68692213760.000000Kb 67082240.000000Mb 65510.000000Gb
Will dereference sock_diag_handlers[57]
Shit, or what?
hmmr@ke:~/D/incoming/mpougatsa_me_krema_kai_milko] ./woopme 2

Linux kernel >= 3.2 NETLINK_INET_DIAG 0day
by huku <huku _at_ grhack _dot_ net>

Using target "Fedora Core 17 3.5.5-2.fc17.i686 #1"
Current uid is 1000
Sucking up the whole VM space
Creating 1G file...100.00%
70340826890240b 68692213760.000000Kb 67082240.000000Mb 65510.000000Gb
Will dereference sock_diag_handlers[57]
Shit, or what?
hmmr@ke:~/D/incoming/mpougatsa_me_krema_kai_milko] ./woopme 0

Linux kernel >= 3.2 NETLINK_INET_DIAG 0day
by huku <huku _at_ grhack _dot_ net>

Using target "Fedora Core 17 3.4.4-3.fc17.i686 #1"
Current uid is 1000
Sucking up the whole VM space
Creating 1G file...100.00%
70340826890240b 68692213760.000000Kb 67082240.000000Mb 65510.000000Gb
Will dereference sock_diag_handlers[57]
Shit, or what?
hmmr@ke:~/D/incoming/mpougatsa_me_krema_kai_milko] uname -a
Linux ke 3.8.0-gentoo #1 SMP Wed Feb 20 15:04:23 EET 2013 x86_64 Intel(R) Core(TM) i5-2500 CPU @ 3.30 GHz GenuineIntel GNU/Linux

A nasty local kernel vulnerability

Posted Feb 26, 2013 12:11 UTC (Tue) by ledow (guest, #11753) [Link]

From what I see, unless it says "Kernel was asswhooped" (or words to that effect) before the last line, then it didn't manage to do anything.

So, looks like you are safe.

A nasty local kernel vulnerability

Posted Feb 26, 2013 12:35 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

> So, looks like you are safe.

looks like you shouldn't be giving out advices (i thought you'd learned that in the past already ;). reading the actual exploit (never mind the posted output) would help explain why it didn't work on the 3.8 kernel.

A nasty local kernel vulnerability

Posted Feb 26, 2013 13:18 UTC (Tue) by ledow (guest, #11753) [Link]

Looks like your attitude readjustment surgery is still pending.

Rather than giving cryptic references and snide remarks, get off your backside and educate people (which you've failed at so many times in the past, it's laughable, precisely because of your superiority complex).

Why didn't it work?

A nasty local kernel vulnerability

Posted Feb 26, 2013 13:35 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

sorry, but RVIs get the RVI treatment, you can't be helped ;). on the other hand i hope the OP will think twice next time before trying an exploit he's never even bothered to read (at this rate it might as well have rm'd his data). and whoever bothers to actually read the code (never mind the README) will find out exactly what works or doesn't work and why. this is not kindergarten where i get to read you a story before the afternoon nap.

A nasty local kernel vulnerability

Posted Feb 26, 2013 14:46 UTC (Tue) by NAR (subscriber, #1313) [Link]

You're wrong, this is the kindergarten and you seem to cast yourself the role of the bully who kicks the kids' sandcastles - just because he/you can. LWN is the place where stuff gets explained. If you don't like it - why are you here?

A nasty local kernel vulnerability

Posted Feb 26, 2013 14:55 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

uhm, explain that sandcastle 'cos i don't see anything ruined here except for a few overgrown egos ;). and if you weren't a blind faszfej yourself, you'd have seen my explanation somewhere above. but then this is the twitterbrain generation here (to borrow khim's expression) that can't digest more than an sms's worth of information never mind putting several of them together. so let me return the question to you: why are *you* here? isn't twitter more suited for your stupid rants?

A nasty local kernel vulnerability

Posted Feb 26, 2013 15:21 UTC (Tue) by ledow (guest, #11753) [Link]

And they say Linus has a potty-mouth. At least he explains, rather than just rides rough-shod over anyone who "doesn't understand".

Sorry, PaXTeam, but my opinion of you hasn't changed since I first saw a comment by you many years ago. And, ironically, you seem to use most of your posts to garner support for your opinion and/or solutions to the problems you see, mainly by telling people how stupid they are to do anything else.

If you were replaced by an emotionless robot with the same technical opinions, I'd have been on your side years ago. As it is, I can't bear to support someone whose idea of useful comment is to provide foreign insults, masked TLA insults (I'm presuming, Google doesn't actually pop up anything for that), announce your superiority and still not come up with an explanation.

The explanation you were after "It hard-codes memory addresses for known kernels". The logical next question is then: How hard is it to find those addresses for the kernel in the example above, and test the exploit properly?

Hell, if I was in your place, I'd make a working exploit for a particular kernel if it's that easy to do so from the code given, and demonstrate your skills rather than mouth off about them (You'll notice that your "explanatory" post was posted after my initial post above - and still that doesn't demonstrate that a newer kernel is or is not vulnerable, only that some well-known kernels have values hardcoded).

Some of us don't touch kernel stuff precisely because we don't have the time/skill/inclination to understand it past a passing glance, and at worst a sarcastic comment would have achieved some education, rather than a flame-thread of back-and-forth.

Subscriber or not, you're putting people off - off this site, off commenting, off learning, and off your projects. If it's a choice between a site with *just* people like yourself, or a site *without* people like yourself, I know which I'd choose every time. I haven't yet said the same of any other contributor on here.

A nasty local kernel vulnerability

Posted Feb 26, 2013 15:33 UTC (Tue) by gowen (guest, #23914) [Link]

It's just marketing.

PaXTeam need to constantly imply that they know stuff that nobody else knows to sell their product. Their business relies on not freely sharing information about kernel vulnerabilities. Openness and disclosure is against their business interests - snidery, vagueness and implication is their stock-in-trade.

They need to give the impression of being permananently ahead of the game.

Rise above it.

A nasty local kernel vulnerability

Posted Feb 26, 2013 16:02 UTC (Tue) by spender (subscriber, #23067) [Link]

LWN.net: where people are allowed to make up complete lies and the facts don't matter -- just be civil!

Can you please point me to this "business" you speak of? The PaX Team's website is http://pax.grsecurity.net. Can you please show me the URL to the "buy" button? All i see is freely-available documentation and source code! The PaX Team does not even accept donations!

I thought not freely sharing information about kernel vulnerabilities was the business of the upstream developers ;)

As for being permanently ahead of the game, it's not an impression but an obvious fact, whether you like that fact or not.

-Brad

A nasty local kernel vulnerability

Posted Feb 26, 2013 16:24 UTC (Tue) by gowen (guest, #23914) [Link]

Become a Sponsor
Sponsors receive personal support, audits of RBAC policies and kernel configurations, the ability to request features tailored to your organization, and presence on the website. Sponsorship begins at 100 USD/mo. To become a sponsor of grsecurity, email spender@grsecurity.net.

http://grsecurity.net/sponsors.php

It's not a support contract -- it's just that they give you money, and you give them support.

A nasty local kernel vulnerability

Posted Feb 26, 2013 16:30 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

I was under the impression that PaXTeam is not (part of) grsecurity, even if they are being provided web hosting by grsecurity.

A nasty local kernel vulnerability

Posted Feb 26, 2013 16:43 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

sorry to burst your bubble, but i'm not spender, i'm not doing grsecurity, i do PaX. spender has very kindly provided hosting since i had to move last time off some free hosting. we've been working together on our projects for over a decade but the business side (for the sponsorship otherwise companies have a hard time to donate) is his, not mine. so what's next? a new excuse? an apology? nah, one can't expect much from random LWN ranters, can we? ;)

A nasty local kernel vulnerability

Posted Feb 26, 2013 17:24 UTC (Tue) by gowen (guest, #23914) [Link]

An apology? ok. I'm very sorry for not being convinced that you're not the same person.

A nasty local kernel vulnerability

Posted Feb 26, 2013 17:40 UTC (Tue) by arjan (subscriber, #36785) [Link]

as having someone who has interacted with both Spender and PaxTeam, I can say that they are certainly not the same person.

I've in the past clashed with PaxTeam on issues at times, but I do respect his technical ability greatly; he/she does not deserve this thrashing in this forum, even if the communication style is a bit brisk.

A nasty local kernel vulnerability

Posted Feb 26, 2013 18:26 UTC (Tue) by k8to (subscriber, #15413) [Link]

The one statement does not imply the other. Perhaps there are other reasons though.

A nasty local kernel vulnerability

Posted Feb 26, 2013 22:03 UTC (Tue) by nix (subscriber, #2304) [Link]

One of the unfortunate consequences of posting in a style guaranteed to offend people and piss them off is that one will offend people and piss them off. Wishing that this didn't happen will not change it: one cannot reprogram the social instinct of everyone with whom one interacts. Eventually, PaXTeam may learn this (or start to care that it happens and dooms him to perpetual Cassandrahood), though I don't hold out much hope.

A nasty local kernel vulnerability

Posted Feb 26, 2013 22:53 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

it probably wouldn't hurt if you studied http://en.wikipedia.org/wiki/Sampling_bias a bit ;).

A nasty local kernel vulnerability

Posted Feb 26, 2013 17:15 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

what a mouthful we have here ;). let's go in reverse so that the timeline is clear:

> at worst a sarcastic comment would have achieved some education

there you go: https://lwn.net/Articles/539942/ (in case it's still not obvious, 'supported' refers to 'supported by the exploit' because it was castrated before publication, something that should have been obvious to anyone who bothered to read the README).

so the first conclusion is that you missed that opportunity of enlightenment. let's see how you fared next:

> Some of us don't touch kernel stuff precisely because [...]

right, so you admit to not understand anything about the exploit, the exploited bug, the affected kernels, etc. and you never read the README either (you don't need to be a programmer to understand it). and you didn't read the explot log to which you responded either else you'd have noticed the very clear discrepancy between the to-be-exploited kernel's version and what the exploit itself offered. *yet* you felt utterly compelled to share your non-existent wisdom with the rest of us and managed to actively mislead the poor OP at the same time (we call it giving someone a false sense of security). what do you think of yourself in that light? what i think is that the proverbial road to hell is clearly paved with arrogant incompetence.

one would think at this point you'd have realized the errors of your way, but clearly that's assuming too much of your intellect. watch this:

> The explanation you were after "It hard-codes memory addresses for known
> kernels".

so what did i post almost an hour before your first rant (not that it wasn't already in the published sources that you could have read as well)? that's right, these very pesky hard-coded memory addresses for known kernels (known to the trimmed down exploit, that is).

> The logical next question is then: How hard is it to find those
> addresses for the kernel in the example above, and test the exploit
> properly?

the logical next answer is that you go look at the exploit source code (did i say that too many times already?) and read what those addresses are and realize that they're a grep away.

> Hell, if I was in your place,

hell, i wish you weren't, you'd do too much damage due to incompetence.

> [...]I'd make a working exploit for a particular kernel if it's that
> easy to do so from the code given, and demonstrate your skills rather
> than mouth off about them

actually, there was nothing mouthing off about anyone's skill, or it was at most about the lack thereof (that'd be your reading comprehension ;). and why on earth would i give people a loaded gun when i've never done it in the past? as you can see, the average person is way too careless, the only reason the OP's box didn't get erased is because the exploit publisher was kind enough, which is a rather rare occurance these days as most dangerous stuff stays private and public 'leaks' often come with some extra baggage you really don't wish to run.

> (You'll notice that your "explanatory" post was posted after my initial post above

and also before your rant, yes.

> and still that doesn't demonstrate that a newer kernel is or is not
> vulnerable, only that some well-known kernels have values hardcoded).

a kernel is not vulnerable because an exploit exists against it. a kernel is vulnerable because it has an exploitable bug. and we know that 1) such a bug does exist in this case, 2) which kernels are affected (did you even read the article itself?). so if you want to know if you're vulnerable, you go check you kernel version, you don't need an exploit for that. if you're a curious cat or have other nefarious intents, get off your butt and at least read the code you're about to run and figure out what needs adjustment. and no, i'm still not giving you that loaded gun, i hinted at enough details already that should get you going if you really want to.

last but not least, if i cared about your opinion, you'd think i'd have shown some results by now. clearly, i don't give a shit but then i guess it won't stop you from trying (what was that Einstein quote about insanity again? ;).

A nasty local kernel vulnerability

Posted Feb 26, 2013 19:37 UTC (Tue) by gabucino (guest, #72504) [Link]

> If it's a choice between a site with *just* people like yourself, or a site *without* people like yourself, I know which I'd choose every time.

Is this your emoblog now? Sorry for the intrusion.

A nasty local kernel vulnerability

Posted Feb 26, 2013 15:23 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

I'm curious: Are you a lazy Hungarian, or a pretentious non-Hungarian?

A nasty local kernel vulnerability

Posted Feb 26, 2013 15:47 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

i've always posted from my freemail.hu address, does that answer the question? :)

A nasty local kernel vulnerability

Posted Feb 26, 2013 14:39 UTC (Tue) by heijo (guest, #88363) [Link]

Probably because it uses hardcoded addresses, hardcoded structure member offsets or hardcoded assumptions about local variable layout on the stack?

It's pretty obvious.

A nasty local kernel vulnerability

Posted Feb 26, 2013 17:14 UTC (Tue) by drag (subscriber, #31333) [Link]

> Looks like your attitude readjustment surgery is still pending.

When you give out shit advice like "So, looks like you are safe." and they you react all butt-hurt about being slapped down... YOU are the one that needs the attitude adjustment.

Everybody, especially in technical circles, gets beyond their means sometimes. And when in security this often leads to giving out poor and misleading advice that will end up giving people false senses of securities, cause them to be vulnerable when otherwise they would take steps to mitigate the problem, and/or cause them a huge amount of unnecessary work and worry that doesn't really accomplish anything.

Nothing PaxTeam said is outragious, insulting, or wrong. He is correct and you should take the advice. I've seen plenty of times people behaving very poorly, being arrogant, and treating other people like shit because they know more about a subject then they do... but I don't see that in this case. You told something that was very misleading and can potentially open up the original poster and a lot of other people,

It would of been worse if PaxTeam didn't say anything. Hopefully people will pay attention to what he is saying.

As far as the rest of the thread goes.. you can go on and attack PaxTeam and Spender, but even if you do manage to discredit their message that won't make Linux any more secure.

From my perspective it seems that things have gone downhill a bit in Linux-land. People are starting to depend on things like SeLinux and sandboxing way too much and those techniques only very effective if you are willing to put a lot of time into customizing rules and such.. which almost nobody does except in specific enterprise environments.

A nasty local kernel vulnerability

Posted Feb 26, 2013 18:49 UTC (Tue) by khim (subscriber, #9252) [Link]

It would of been worse if PaxTeam didn't say anything.

No. It would be better. Much better. In a sense PaXTeam and Spender spent so much time teaching people that they are the boys who constantly cry the wolf that any advice from them immediately justifies the thing they are objecting against.

Hopefully people will pay attention to what he is saying.

They do - just not in the way you expect. Typical reaction is "ah, I see — only these worrywarts are panicking… which means at this stage it's problem for Pentagon and/or FBI, but for us, mere mortals, it's not something to worry about".

A nasty local kernel vulnerability

Posted Feb 26, 2013 19:04 UTC (Tue) by hummassa (subscriber, #307) [Link]

> Typical reaction is "ah, I see — only these worrywarts are panicking… which means at this stage it's problem for Pentagon and/or FBI, but for us, mere mortals, it's not something to worry about".

That, and getting all red in the face when shit hits the fan, eh? The problem with thinking someone is "the boy the cries wolf" (independently of the truthiness) is that eventually the wolf comes (it always does).

Ah, and the obvious "ad hominem fallacy" thing. Meaning that anyone who succumbs to the "typical reaction" is just plain wrong...

A nasty local kernel vulnerability

Posted Feb 26, 2013 19:38 UTC (Tue) by khim (subscriber, #9252) [Link]

The problem with thinking someone is "the boy the cries wolf" (independently of the truthiness) is that eventually the wolf comes (it always does).

Sure, but how much harm does it make? People have learned to live with all the trojans, viruses and other, more benign, crapware on their systems. They know they lose some money from the crashes and periodic reinstalls but as long as this amount if less then the amount you need to spend to keep your system bullet-proof it's wise investment.

That's what people like PaXTeam and Spender can't understand at all: most people accept the fact that their computers are vulnerable as matter of fact, not something to cry about. After all their homes are vulnerable (few of us live in castles with three redundant layers of walls), their cars are vulnerable (just sprinkle the car with some millet where there are lots of birds and watch how $$$ body is destroyed), etc. Some level of security is desirable, of course (we have locks in our homes and cars), but it's all relative. For Joe Average the question is not "can someone attack me", but "how much it'll likely to cost me if I'll not go and spend days patching this vulnerability". Answers from PaXTeam and Spender are absolutely unhelpful and thus the default "risk is obviously still quite low" answer is assumed.

That, and getting all red in the face when shit hits the fan, eh?

Well, nobody likes pickpockets and people become angry when they are robbed by them but it does not mean they will use locked down safe to carry their couple of $10 bills next time.

A nasty local kernel vulnerability

Posted Feb 26, 2013 21:39 UTC (Tue) by aggelos (subscriber, #41752) [Link]

Two points:

a) Your analogy to the physical world is inapplicable as the potential for exploitation at a massive scale changes the economics considerably.

b) The Average Joe has no clue about the severity of a vulnerability or about the sophistication of the current generation of attacks. It would be good news if your Average (I assume, Professional) Joe did an actual cost/benefit analysis but, at least in my experience, they generally have neither the expertise nor the professionalism to do that.

A nasty local kernel vulnerability

Posted Feb 27, 2013 7:30 UTC (Wed) by paulj (subscriber, #341) [Link]

An individual with 1 computer cannot be exploited at a massive scale. Indeed, even if exploitation of many individuals - at a massive scale - occurs, the risk to any 1 individual may still be minimal.

The economics changed for the attackers, allowing them greater scale. However, it hasn't really changed the economics for each individual or even businesses, in the main. What khim wrote stands for them.

A nasty local kernel vulnerability

Posted Feb 27, 2013 10:27 UTC (Wed) by khim (subscriber, #9252) [Link]

The economics changed for the attackers, allowing them greater scale. However, it hasn't really changed the economics for each individual or even businesses, in the main.

It's even worse then that. This discussion was started when it was known that "economies of scale" was broken (automatic exploit didn't work). Now the question becomes extremely technical: yes, we know that you need some offsets for any custom build of kernel, but is it something attacker can automatically guess from System.map or is it something attacker need to painstakingly dig from memory using esoteric debugging techniques? The natural assumption is that you need to use esoteric debugging techniques, but if the situation is different in some cases you'll never hear from PaX && Brad directly about that which turns their messages to classic "cry wolf" messages.

A nasty local kernel vulnerability

Posted Feb 27, 2013 10:47 UTC (Wed) by paulj (subscriber, #341) [Link]

If I understand the earlier discussion correctly, the PoC exploit doesn't automatically determine the offsets, but other code exists to do that. All you that needs to be done is combine the two - PaXTeam and Spender just havn't done so (perhaps deliberately). In which case, the attack can work perfectly well at scale.

As per your comment earlier, it's still not a massive problem for many specific entities, even if it's still a significant problem for the general internet eco-system (giving bad people control of things to use as staging posts for further bad stuff, etc.).

A nasty local kernel vulnerability

Posted Feb 27, 2013 11:12 UTC (Wed) by khim (subscriber, #9252) [Link]

If I understand the earlier discussion correctly, the PoC exploit doesn't automatically determine the offsets, but other code exists to do that.

Yes, that's true, but can you glean this information from summarily unhelpful looks like you shouldn't be giving out advices (i thought you'd learned that in the past already ;). reading the actual exploit (never mind the posted output) would help explain why it didn't work on the 3.8 kernel message?

Yes, message is 100% correct, but as we now know thread opener already knew just why exploit does not work — but he probably had no idea if there are exist code which can automatically find offsets or not. And instead of giving him the useful information the only thing message contained is sneers.

As per your comment earlier, it's still not a massive problem for many specific entities, even if it's still a significant problem for the general internet eco-system (giving bad people control of things to use as staging posts for further bad stuff, etc.).

Right, but can you ever find this information (the only information interesting for average LWN reader) in PaX && Brad opuses? Nope. But you'll find plenty of riddles and endless hubris in them. Not a good way to attract people's attention, really.

A nasty local kernel vulnerability

Posted Feb 27, 2013 12:57 UTC (Wed) by spender (subscriber, #23067) [Link]

Hi khim,

While you were busy attacking your straw man (if you think our position involves massive security spending or constant patching, you clearly know nothing about us), I was posting exploitation notes in another forum where such information is actually valued instead of squandered on the likes of you. All the information you could want is available -- if you cared about security (which it does not seem that you do) you would be using additional sources to obtain it.

Would you prefer that I publish a weaponized exploit for the vulnerability or something? I can only imagine the kinds of complaints that would generate here and elsewhere. You appear to be whining about it not existing and insinuating that that's because it's impossible. The exploitation notes should clear up that this is trivial on vanilla Linux, not that facts appear to matter to you.

http://www.reddit.com/r/netsec/comments/198g7i/cve_201317...

I much prefer other forums where idiotic comments are downvoted to obscurity where they belong. It makes it much easier for people to see useful content.

-Brad

A nasty local kernel vulnerability

Posted Feb 27, 2013 13:12 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

It seems to me that the overlap between "community capable of using downvote-to-obscurity systems responsibly" and "communities with any genuine need for a downvote-to-obscurity system in the first place" is likely to be extremely small. Downvote-to-obscurity systems don't directly cause groupthink, but they certainly facilitate its development.

A nasty local kernel vulnerability

Posted Feb 27, 2013 14:17 UTC (Wed) by khim (subscriber, #9252) [Link]

While you were busy attacking your straw man (if you think our position involves massive security spending or constant patching, you clearly know nothing about us), I was posting exploitation notes in another forum where such information is actually valued instead of squandered on the likes of you.

Let me translate from English to English: while people here tried to understand what effect this exploit can have you've only posted snide remarks here and expressly refused to help because audience here does not worship you enough. It's your choice, of course, but then you should not be surprised by the reaction.

I mean: you've spent a lot of time and efforts to make sure people on LWN will perceive you as "this asshole who never says anything concrete and just plays some great guru who has right to ridicule everyone else without a substantial reason" — and now you are surprised that people treat you as such asshole? Few people who do know what you actually do are trying to fix this perception but of course they can't do anything: direct words "from horse's mouth" are more potent by far then third-party narrations.

Would you prefer that I publish a weaponized exploit for the vulnerability or something?

Nope. Sane explanation of what goes on will be enough. Here is the example of sane explanation. Here is the example of snakeoil salesmen pitch (mixed with the deep technical details which are of no interest to most users). People who are sold on grsecurity already don't need it and people who are not sold will start to ignore it after few repeats of "you were owned before the distro even pushed an update" with no observed consequences (that's the "wolf" cry I've talked about).

A nasty local kernel vulnerability

Posted Feb 27, 2013 15:19 UTC (Wed) by malor (subscriber, #2973) [Link]

As far as I'm concerned, you're both towering assholes, and all this verbiage is accomplishing precisely nothing.

You'd both do well do stop waving your electronic genitalia.

A nasty local kernel vulnerability

Posted Feb 27, 2013 15:46 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> while people here tried to understand what effect this exploit can have

first, they did not (provide evidence that they did. no, running the exploit is not evidence of that.) second, as i explained so many times, you don't care about exploits, you care about exploitable bugs, regardless of an exploit that you may very well never get your hands on (but your attackers may/will). please stop spreading this bullshit attitude, this is exactly one of the biggest problems with people who are in charge of security somewhere but are incompetent to the point that without a weaponized exploit or worse, getting completely owned they would never consider fixing the problems.

> you've only posted snide remarks here and expressly refused to help
> because audience here does not worship you enough.

that help was already in the article, including the linked ones too: there is an exploitable kernel bug, no ifs and buts about it. go fix it yourself if you can, wait for your distro otherwise. no other piece of information is needed if you only care about defense! and forgive me if i refuse to play on the attacker side and help people write weaponized exploits. pretty please? ;)

> I mean: you've spent a lot of time and efforts to make sure people on
> LWN will perceive you as "this asshole who never says anything concrete
> and just plays some great guru who has right to ridicule everyone else
> without a substantial reason"

do you have evidence that we don't provide 'anything concrete'? spoonfeeding weaponized exploit info doesn't count of course (albeit spender has been quilty of even that but then i don't expect you know, it's so much easier to throw out random shit without evidence, aint't it ;). and yes, we do ridicule idiots such as yourself, but you see biased samples don't statistics make (may i refer you to the same wikipedia article that i suggested nix to read as well? ;).

> and now you are surprised that people treat you as such asshole?

and that statistics is based on what evidence exactly? oh wait, the usual 'i made it up because that is what fits my distorted reality'. second, what does it matter (seemingly to you, but not us) what anyone thinks of us? does that change anything? not us apparently. then why do you care? do *you* change when others think of you as an asshole? yeah, i didn't think so either ;). third time i'm reminded of Einstein. the guy knew something.

Enough?

Posted Feb 27, 2013 16:18 UTC (Wed) by corbet (editor, #1) [Link]

I get the sense that the few people still following this thread have a fairly good idea of what the participants think of each other at this point. So maybe we could stop here? Seriously, personal attacks don't help the conversation, let's try to do rather less of that, OK?

A nasty local kernel vulnerability

Posted Feb 27, 2013 11:00 UTC (Wed) by aggelos (subscriber, #41752) [Link]

An individual with 1 computer cannot be exploited at a massive scale. Indeed, even if exploitation of many individuals - at a massive scale - occurs, the risk to any 1 individual may still be minimal. The economics changed for the attackers, allowing them greater scale. However, it hasn't really changed the economics for each individual or even businesses, in the main. What khim wrote stands for them.
Sigh. Being able to attack at a massive scale (and being able to easily monetize exploited systems) makes writing an exploit way more attractive to a group of skilled people with no qualms about how to make money (nevermind the power trip factor). That means that any individual's chance of getting owned is significantly higher than if mass exploitation wasn't possible. Therefore mass exploitation changes the economics of a cost/benefit analysis. QED.

A nasty local kernel vulnerability

Posted Feb 27, 2013 1:34 UTC (Wed) by hummassa (subscriber, #307) [Link]

> Sure, but how much harm does it make?

67 billion a year in the US only, according to the FBI in 2006.

You are correct in stating that you don't have to have perfect security. But it's like the bear/shotgun joke goes: you don't have to outrun the bear, you have to shoot your mate in the knee so you can outrun *him*. When PaX && Brad "cry wolf", they are actually showing you that your mate can outrun you, so you're bear snack!

Bonus: mixing two animal-world metaphors... :-D

A nasty local kernel vulnerability

Posted Feb 27, 2013 10:21 UTC (Wed) by khim (subscriber, #9252) [Link]

When PaX && Brad "cry wolf", they are actually showing you that your mate can outrun you, so you're bear snack!

Nope. They "actually showing" that your boots have scuffs — but then refuse to say if your boots are lightly affected or are ready to fall apart at the seams. You can stop to try to mend them (which places you closer to the bear but gives you hope that you'll be able to run faster in the future) or you can ignore them and hope boots will hold till the next town.

67 billion a year in the US only, according to the FBI in 2006.

Which is less then 1% of GDP and in the same ballpack as $83 billion from patent trolls. IOW: yes, it's a problem, but it's not the problem and it's certainly not something you need to spend all your resources on.

A nasty local kernel vulnerability

Posted Feb 26, 2013 21:44 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

uhm, do you have stats on how many times we cried wolf (assuming you mean we said something was a security bug where it wasn't)? we're not 100% correct of course but much closer to it than to 0% so it's a far cry (pun intended) from crying wolf ;).

as for the typical reaction, where's your data from? the data i have say that people who care about security are avid readers of spender's changelog to the point that the just released ubuntu fix for this very problem misattributed the bug to spender instead of Mathias. the people who don't care (mostly because they don't even know they could or should) simply expect their more or less regular system updates to fix problems that they or others have experienced. details don't matter for them, regardless of what we or anyone else have to say about them, that information doesn't even reach them so we can't talk about reaction as there's nothing to react to in the first place.

A nasty local kernel vulnerability

Posted Feb 27, 2013 10:45 UTC (Wed) by khim (subscriber, #9252) [Link]

uhm, do you have stats on how many times we cried wolf (assuming you mean we said something was a security bug where it wasn't)? we're not 100% correct of course but much closer to it than to 0% so it's a far cry (pun intended) from crying wolf ;).

And this answer shows what's wrong with you messages succinctly. You assume people want to know about all security bugs for some reason. But why should they care? Do you dig all the information about all the internal incidents on the power stations which power you computer or all the problems with pumping station or all the problems with all the farmers who grow food you eat? I doubt it: you only want to know about incidents which can actually affect you! And Joe Average is the same: security bugs which have little chance of affecting him directly are of no interest to him!

From that POV you "cry wolf" all the time and you are much, much, MUCH closer to 0% then to 100%, sorry.

the data i have say that people who care about security are avid readers of spender's changelog to the point that the just released ubuntu fix for this very problem misattributed the bug to spender instead of Mathias.

Of course! That's their work! It's similar to nuclear power plant workers: they study information about incidents on other plants diligently, indeed. But general public? No, it's not what they want to know and it's not what they are supposed to know. When you bait these people and ridicule them because they don't diligently study all your patches you just show your hypocrisy, nothing more, nothing less.

details don't matter for them, regardless of what we or anyone else have to say about them, that information doesn't even reach them so we can't talk about reaction as there's nothing to react to in the first place.

Sure. Detail don't matter for them but if they'll know that situation is so dire that nuclear station near them can blow up at any moment they should care and they will care. That's about what people expect from discussions on LWN — and that's what you expressly refuse to discuss. You show some snippets of information and then laugh on people who can try to understand if they actually should care about it or if they should expect their more or less regular system updates to fix problems. After few such repeats people learn that it's more-or-less impossible to receive useful information from you and they know that after bazillion of your "wolf" cries wolf didn't come thus they assume you again talk something they can safely ignore.

A nasty local kernel vulnerability

Posted Feb 27, 2013 15:24 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> And this answer shows what's wrong with you messages succinctly.

sure, if you're talking about your own ;). you see, you didn't answer a single question of mine. do you have stats or not? you don't. do you have examples where we cried wolf? you don't. facts speak, strawmen don't.

> You assume people want to know about all security bugs for some reason.

quote me back on that or you just made this up. seriously, do find a quote from me where i said anything even remotely close to that. you won't because you can't because i never said anything like that (never mind that right in the very post you responded to i said myself that there're people who care to whatever extent and there're people who don't care). making reality fitting your distorted world doesn't work without backing up with (preferably less distorted ;) evidence. so go find some (this goes for all your other posts too, but i'll address some of them there).

> And Joe Average is the same: security bugs which have little chance of
> affecting him directly are of no interest to him!

you're wrong, did you even read my post you responded to? it's not only that the average user (most people) don't care about bugs that don't affect them, they don't care about *anything* whatsoever because they don't even *know* that such things can exist (and the few who the mass media manages to reach with this information still don't *understand* so they're not in the position to be able to care)!

> From that POV you "cry wolf" all the time and you are much, much, MUCH closer to 0% then to 100%, sorry.

here we go again, without any shred of evidence of what exactly we did that you think was crying wolf? a single example pretty please (although i'd still prefer that stat of yours ;)? and i mean examples that exist on the internet, not in your head only.

> When you bait these people [...]

evidence please or you made this up.

> [...]ridicule them because they don't diligently study all your patches

yes, we critize people who should care about security but don't. you also critize everyone who doesn't think your way, what's your point then?

> you just show your hypocrisy, nothing more, nothing less.

i suggest you look up that word, it doesn't mean what you think it does (hint: it'd apply to us if we expected others to care about security whereas we wouldn't care at the same time, i think even you admitted that that's not the case ;).

> That's about what people expect from discussions on LWN

provide evidence or you made this up. be careful 'cos i have my own quotes directly from lwn posts where people explicitly asked the exact opposite of what you're suggesting here ;).

> and that's what you expressly refuse to discuss.

what i discuss is not up to you to decide mon ami, it's up to me. you don't have to like my choices any more than i or anyone else has to like yours or anyone else's. welcome to the real world. with that said, i think i provided about 1000x more useful information about security bugs over time here and elsewhere than you ever will (your whining doesn't count ;).

> You show some snippets of information

did you even read what i posted? it was *public* information, linked straight from the article. you know there's some irony in that you're showing the exact symptomps of the twitterbrain that you so critized in the past yourself ;).

> and then laugh on people

evidence or you made this up too. if anything, i was worried about them destroying their systems by being so careless when they ran an exploit they didn't understand (the loaded gun example, see somewhere above).

> who can try to understand if they actually should care about it or if
> they should expect their more or less regular system updates to fix
> problems.

khim, if you don't understand a topic, can you please stay out of discussing it, never mind giving out advices to the laymen? i wrote about this before in this very thread but let me repeat it: your kernel is *not* exploitable because someone posts a working exploit to the public! your kernel is vulnerable because it has an exploitable bug! can you digest that? do you understand that testing your system this way would only give you a false sense of security? yeah, i don't expect you do. so please take it on faith that you should not care because you see an exploit in the wild, you should care because there is an exploitable bug in your system, don't wait with the upgrade till an exploit appears.

> After few such repeats

more evidence wants to be seen.

> people learn that it's more-or-less impossible to receive useful
> information from you[...]

first, i didn't know i was supposed to provide such a service. second, when spender or me did provide such information in the past, we were criticized for *that*. i don't think you can have it both ways ;).

> and they know that after bazillion of your "wolf" cries wolf didn't come

this is again the same lie you keep repeating and based all your rants on. so prove it or admit you made this up.

A nasty local kernel vulnerability

Posted Feb 27, 2013 20:46 UTC (Wed) by khim (subscriber, #9252) [Link]

i suggest you look up that word, it doesn't mean what you think it does (hint: it'd apply to us if we expected others to care about security whereas we wouldn't care at the same time, i think even you admitted that that's not the case ;).

It's absolutely the case. Do you know or care who and how produces electric power for your home? Do you know or care abut who and how pumps water? Do you know and care about all the food sources (and all the chemicals used in this process) ? Or do you pick one narrow form of security (IT-related stuff) and assume all other forms of security are somehow less important? Why do you think it's more important and why do you think other should care about GMO less then they care about out-of-bounds access in the Linux kernel?

A nasty local kernel vulnerability

Posted Feb 27, 2013 21:12 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

this is LWN, the topic is a linux kernel vulnerability, *of course* everyone (except perhaps you) talks about security as it relates to computers. you want to discuss other kinds of security? find a more suitable forum for it ;). then and there i will tell you what i think and know about those other areas, but it's off topic here afaik. alternatively, if you can get Jonathan to agree that it's not, we can discuss it here. in short, the logical mistake you made is that if i write about something, it also means that i don't care about anything else i didn't write about. that's an obvious fallacy.

A nasty local kernel vulnerability

Posted Feb 27, 2013 21:55 UTC (Wed) by khim (subscriber, #9252) [Link]

And now for some meat.

him, if you don't understand a topic, can you please stay out of discussing it, never mind giving out advices to the laymen?

Well, that's exactly your problem: as someone who's working on security solutions (although not on Linux-kernel related security solutions) I do understand the topic. At least I understand it well enough to expose your "snake oil salesmen" pitch.

i wrote about this before in this very thread but let me repeat it: your kernel is *not* exploitable because someone posts a working exploit to the public! your kernel is vulnerable because it has an exploitable bug! can you digest that?

Of course I can! It's truth, nothing except truth, the only problem: it's useless truth!

In the absence of "black hats" even bazillion security holes in your system don't matter: there are noone to exploit them. Easy enough to digest. Also easy to understand that this is unrealistic case: we do know that "black hats" dwell out there.

Ok, what about another case: all-knowledgeable adversary. In this case, obviously, upgrade is also entirely useless: you replace one vulnerable kernel with another also vulnerable kernel (all kernels till now had a security bugs and there are nothing to suggest that anyone here have 100% security-bug-free Linux kernel).

Ah-ha. So now we see that the only case where all these security patches and disruptions ever make sense lies in the world where we do have an adversary but where said adversary does not posses an omniscience.

Which basically means that "what knowledge potential attackers have about exploit" is the most important, central question for the layman. It may be pretty murky at times (the only case where answer is 100% clear is when you can say something like "I've personally added this exploit to dozen of rootkit sets which are sold on blackmarket" — and for some reason people don't like to say so even if that's exactly what they did), but it's vital.

Now, situation like this one ("I don't know if this exploit is in rootkits by now or not, but all the ingredients are publicly known thus we can expect it can be exploited soon") is not that much better, but it's still better: you know that probably only expensive rootkit can exploit this vulnerability on custom kernels while cheap ones will only target few popular distributions.

If someone wants to rush to upgrade or not because there are pretty easy to use vulnerability depends on the exact circumstances, but to say "please take it on faith that you should not care because you see an exploit in the wild, you should care because there is an exploitable bug in your system, don't wait with the upgrade till an exploit appears" is exactly to "cry wolf" needlessly. Not all security bugs are equally dangerous (although there are bias: bugs which are obviously high-priority are easy to exploit but from time to time people invent clever ways to exploit bugs which look hard to exploit at first glance) and you do know that most likely both old kernel and upgraded one have exploitable security holes. Thus you need to know what makes this particular bug easy (or hard) to exploit and — more importantly for the layman — how easy (or hard) is it to exploit in reality.

So now back to the question:

do you understand that testing your system this way would only give you a false sense of security?

I understand that now, but it's not at all obvious from the source of the presented exploit. You either need to dig deeper (to try to understand how exploit works and then study the relevant kernel sources) or you need more context (if someone who wrote exploit says that "it's pretty easy to add support for custom kernels — 10 minutes, may be couple of hours if System.map is not present" then it's one thing, if it's "we needed to run this kernel for hours under an emulator to find this offsets" then it's quite different thing).

And I'm ready to admit: you have explained the situation here, that's true — but it was done after some snide remarks which don't enlighten the situation at all. These were entirely unnecessary.

A nasty local kernel vulnerability

Posted Feb 26, 2013 21:58 UTC (Tue) by nix (subscriber, #2304) [Link]

I have to agree with PaXTeam here (yes, it can happen). When did they cry wolf about actual exploits? One can disagree with PaXTeam and spender regarding their attitude, their interaction with the kernel community, the hopelessness of their task as long as they specialize principally in making people hate them, all sorts of things -- but if they say there is a security hole somewhere, they are more or less guaranteed to be right. As I've said before, that's the tragedy here: their frankly terrible interpersonal skills doom them to being Cassandras, crying the truth but universally ignored.

A nasty local kernel vulnerability

Posted Feb 27, 2013 10:48 UTC (Wed) by khim (subscriber, #9252) [Link]

if they say there is a security hole somewhere, they are more or less guaranteed to be right

Sure, but is it serious enough to drop everything and start shutting down some services or is it minor enough to schedule kernel update early next quarter? These are the things most readers of LWN wonder about. Some may be more technical and may care about juicy details of the bug — but these are in the minority.

A nasty local kernel vulnerability

Posted Feb 26, 2013 21:38 UTC (Tue) by stijn (subscriber, #570) [Link]

"Enter your comment text below. Please try to be polite, respectful, and informative". (I consider this to be informative, if redundant).

A nasty local kernel vulnerability

Posted Feb 26, 2013 21:56 UTC (Tue) by nix (subscriber, #2304) [Link]

People are starting to depend on things like SeLinux and sandboxing way too much and those techniques only very effective if you are willing to put a lot of time into customizing rules and such.
That's so so true of SELinux, but there's no way it's true of properly implemented sandboxes. How much time do you have to put into customizing any of the sandboxes in Chrome? (The answer is 'none': you may not even realise they are there, but they're making it a heck of a lot harder to compromise the system through a vulnerability in the network-exposed parts of Chrome. There are three on Linux, one of which is more or less deprecated. You'll only notice if you look at about:sandbox or none of them initialize correctly, in which case Chrome will warn you.)

That's what security that actually makes a difference looks like. Security that works even if nobody has to do anything to turn it on, security that requires no configuration.

A nasty local kernel vulnerability

Posted Feb 26, 2013 13:27 UTC (Tue) by edeloget (subscriber, #88392) [Link]

Like @PaXTeam said, the fact that the exploit did not work on your system is not an indication that your system is safe. It's an indication that the targets[] array does not contain information that pertains to your system.

If you are able to find reliable kernel addresses for prepare_kernel_cred() and commit_cred(), then you can test the exploit again.

A nasty local kernel vulnerability

Posted Feb 26, 2013 23:23 UTC (Tue) by smokeing (guest, #53685) [Link]

I'm in no way an expert in kernel, but I did have a look at the code before running the exploit. Somehow, I had a feeling I will be safe (not least because mine is not a distro kernel), and so eventually I gave it a shot. Indeed, it didn't work. Yes, it was silly and stupid. Curiosity will kill this cat.

But, wow. Looks to me all the rage the guys have meanwhile vented above just waited to happen. I got scared, in a way, coming back to this thread to find 44 responses!

Peace :}

A nasty local kernel vulnerability

Posted Feb 26, 2013 23:40 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

very well then, don't say you weren't warned: http://seclists.org/oss-sec/2013/q1/453 :)

A nasty local kernel vulnerability

Posted Mar 5, 2013 15:40 UTC (Tue) by ortalo (subscriber, #4654) [Link]

Quite the contrary; in my humble opinion, curiosity is the primary legitimate reason for studying an exploit.

From the point of view of the actual protection of a computer, I've always considered (and teached) that exploit-oriented work (when it's not evil) is counter-productive. Most frequently, it takes less time to fix a potential security bug than to check its pratical exploitability. Frequently, you check exploitability because you cannot have trustable feedback on the actual danger and you had better consider a full solution switch.
(Note that there is a critical distinction between no feedback at all as is frequent with proprietary software and disagreement between developers on a piece of software available for public scrutiny as is frequent with open source software. Though that does not necessarily solves the first point.)

Furthermore working on exploits mean working on bad, obscure code that will not be reused (except for bad reasons or endless demonstration); while working on correcting errors is quality improvement and good programming. (Quality improvement is not as rewarding as writing a new scheduler - but still better than finding buffer overflows offsets - and new linux schedulers are so... common... nowadays.)

So... there are also real reasons why such a topic scratches so much itches; those forced (either by public pressure or by careless or manoeuvering managers) to work on exploitability are usually accumulating dissatisfaction. But that's certainly not due to your curiosity.

A nasty local kernel vulnerability

Posted Feb 26, 2013 19:28 UTC (Tue) by gabucino (guest, #72504) [Link]

> So, looks like you are safe.

<micsko_gabor> Igy van.

As of 2013-02-27 10:00 UTC Vanilla kernel updates are still unavailable :(

Posted Feb 27, 2013 10:09 UTC (Wed) by giggls (subscriber, #48434) [Link]

3.4.34, 3.7.10 and 3.8.1 are still unavailable.

Of course it is a 3 line patch only, but I would prefer using official versions instead of custom 3.7.9+ stuff.

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