Known-exploit detection for the kernel

Posted Dec 18, 2013 23:56 UTC (Wed) by spender (guest, #23067)
Parent article: Known-exploit detection for the kernel

There's a 100% chance that if this were merged, some distro will compile in support for it despite it being useless. Yet another in a line of features designed to provide the illusion of security.

It is already trivially circumvented via a single function usable by any other exploit, present in enlightenment:
http://grsecurity.net/~spender/exploits/enlightenment.tgz

But it's cute that discussion continues while those involved are completely oblivious to its futility.

-Brad

Known-exploit detection for the kernel

Posted Dec 19, 2013 0:49 UTC (Thu) by ncm (guest, #165) [Link] (14 responses)

Boldly demonstrating my ignorance... is this comment meant to suggest that there is no need for an attacker to risk possibly-fixed security holes when a variety of holes known not to be fixed is available in a convenient tarball from Brad?

Known-exploit detection for the kernel

Posted Dec 19, 2013 0:58 UTC (Thu) by spender (guest, #23067) [Link] (13 responses)

Not at all correct -- that would be completely irrelevant to the topic at hand since it has nothing to do with 0-days (nevermind that some involved in the discussion threw the term around incorrectly).

Reading the code would be more instructive: cve_chicken_out() in exploit.c

-Brad

Known-exploit detection for the kernel

Posted Dec 19, 2013 1:27 UTC (Thu) by ncm (guest, #165) [Link] (7 responses)

Demonstrating again my ignorance, this seems easily defeated by "chmod 0 /boot/vmlinuz*", perhaps along with similar work in /lib/modules.

Known-exploit detection for the kernel

Posted Dec 19, 2013 1:34 UTC (Thu) by spender (guest, #23067) [Link] (6 responses)

For distro kernels that are easily available on the Internet? (this is why it allows fallback to a vmlinuz in the current directory)

-Brad

Known-exploit detection for the kernel

Posted Dec 19, 2013 8:10 UTC (Thu) by ncm (guest, #165) [Link] (5 responses)

So the real workaround you propose is to determine the distro and kernel version and then check the intended exploits against it before attacking the real kernel. Maybe you use a table of all the likely kernel versions and their well-documented (in-)vulnerabilities.

Suppose, then, that in addition to making /boot and /lib/modules inaccessible, uname() is made to lie or be otherwise uninformative. Are you left with any alternative than to try out your catalog of exploits? If you try the newest one first, the kernel under attack might not have that fault inserted yet. If it fails, you have not exposed yourself, but you still have to try the older ones, and risk exposure. Or maybe any EINVALID return is logged, with the PC where it was noted, so the first try exposes you anyway.

Maybe you restrict yourself to faults that have always been there, and only recently patched, if at all. Then, either you get in silently, or you trip the alarm. This still seems better than being able to try out your whole catalog without worry of being noticed. No doubt I'm still missing something crucial.

Known-exploit detection for the kernel

Posted Dec 19, 2013 12:35 UTC (Thu) by spender (guest, #23067) [Link]

I gave you the exact file and function to look at, and it's clear you haven't even done that, so this will be my last post in this thread. You don't want to learn, you want validation that you could somehow wrap this turd of a feature with the appropriate metal lining to make it useful. It's just not going to happen.

What you propose (which is also what Ingo proposed) will not prevent invisible detection of the vulnerable kernel. I have *many* other methods I can use even in the event everything you mention is implemented.

This is my promise: if any form of this security theater makes its way upstream and into any distro, I will write any code necessary to expose it for what it is.

-Brad

Known-exploit detection for the kernel

Posted Dec 19, 2013 16:06 UTC (Thu) by dgm (subscriber, #49227) [Link] (3 responses)

> So the real workaround you propose is to determine the distro and kernel version and then check the intended exploits against it

Spender's code shows that it's actually easy to look for signs of fixes in the kernel image before trying any exploit, thus defeating the detection scheme.

This could be prevented by making the kernel image unreadable except for root, and in case of using SELinux, only for the bootloader tools.

Known-exploit detection for the kernel

Posted Dec 20, 2013 4:03 UTC (Fri) by shmget (guest, #58347) [Link] (2 responses)

or the good old gentoo way of not leaving /boot mounted. ?
to mount /boot you need to be root.. and if you are root already what's the point....

Known-exploit detection for the kernel

Posted Dec 24, 2013 6:18 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

I am sure that there are other ways to determine what version of he Linux kernel that is running.

'uname -a' comes to mind.

This 'threat detection' is just one of those things that, if you are lucky, can be used to detect some old hack a script kiddie may try on your computer as they just randomly try different things. But any threat beyond the most trivial it would quickly become completely worthless.

Known-exploit detection for the kernel

Posted Dec 24, 2013 9:22 UTC (Tue) by dgm (subscriber, #49227) [Link]

The question is what percentage of the threats a Real World box is exposed to is "trivial". This is not a tool to make the OS invulnerable, but to improve the bottom-line.

Known-exploit detection for the kernel

Posted Dec 19, 2013 7:17 UTC (Thu) by josh (subscriber, #17465) [Link] (4 responses)

You might want to add support for non-gzipped kernels, but yeah, it does look about that simple.

The obvious workaround would be to not put the CVE number in the kernel, but to instead just print "exploit attempt detected at $file:$line" and let it be decoded later. Still easily worked around if you're targeting a particular distro kernel, but if you're targeting a *particular* distro kernel anyway then you could just know which exploits to run against it.

Known-exploit detection for the kernel

Posted Dec 19, 2013 12:19 UTC (Thu) by spender (guest, #23067) [Link] (3 responses)

Some trivial static analysis (the likes of which I already do in enlightenment for other purposes) will defeat that "workaround" easily. Obviously I'm not going to waste time writing code for every possible change that could be made to the "feature" but the fact remains that there's no asymmetry of information here. Whatever eventually gets merged will be known to all and defeated. I guarantee it.

It's clear to me many people want more than anything to believe that this feature will work, regardless of any facts.

-Brad

Known-exploit detection for the kernel

Posted Dec 19, 2013 14:32 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

> Some trivial static analysis (the likes of which I already do in enlightenment for other purposes) will defeat that "workaround" easily.

I'd be curious what kind of static analysis you have in mind.

> It's clear to me many people want more than anything to believe that this feature will work

I don't think anyone believes this mechanism will stop or detect sophisticated attacks. The question remains: will it detect some subset of unsophisticated attacks, enough to make it worth including, or not?

Known-exploit detection for the kernel

Posted Dec 24, 2013 6:30 UTC (Tue) by drag (guest, #31333) [Link]

> The question remains: will it detect some subset of unsophisticated attacks, enough to make it worth including, or not?

The social aspect of it is the problem.

Sure the kernel implementing features like this may succeed at detecting ham-fisted attacks, but the problem you run into is that people will naturally assume that this security feature has merit and will unfortunately actually try to depend on it.

People will write blog posts on how critically important it is to make sure you use a kernel version with this detection enabled in it and so on and so forth. It'll end up in Google's cache when people search 'make sure Linux is secure' or such things and then it'll just get increasingly stupid and self-defeating from then on.

You can see the same thing happen all over the place with various 'linux security features'.

A perfect example of this is things like 'chkrootkit'. People may end up with a hacked website and then install chkrootkit and run it thinking that somehow it will actually be effective at detecting root kits, which it is not. Or schemes that involve checking file checksums using 'rpm' utility. Or things like 'fail2ban' being used to 'secure' ssh, or port knocking, or any other number of silly and hokum things that people try to do to 'improve' their security.

Like anti-virus in Windows there is a actual limited useful application for some of this stuff, but most people are not able to know what that is.

Software security is already hard enough without creating features that add to the confusion with no real benefit.

Known-exploit detection for the kernel

Posted Dec 19, 2013 14:39 UTC (Thu) by vegard (subscriber, #52330) [Link]

Hi Brad,

I'm really grateful that we have people like yourself who are both competent and view security with a critical eye. Your feedback is appreciated. Keep up the good work!

Vegard

Known-exploit detection for the kernel

Posted Dec 20, 2013 0:57 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (3 responses)

"despite it being useless"

Like dusting for prints is useless, because criminals all wear gloves, right? Like it's pointless to own a burglar alarm because any "real" burglar would know how to disable it, right? You're actually making the same mistake the people you don't like usually make, assuming perfection where it's unwarranted.

Ordinarily it's the good guys who have to be perfect. One missed special case and you're exploitable. But in this sort of situation the roles are reversed, one slip by the bad guys and the alarms go off. _Everything_ they try has to be properly insulated so that it can't trigger this sort of alarm, because if just one thing isn't, and the relevant alarm is installed, game over.

Known-exploit detection for the kernel

Posted Dec 20, 2013 1:54 UTC (Fri) by PaXTeam (guest, #24616) [Link] (2 responses)

i'm not entirely sure whether you grasped the proposed feature and spender's criticism (the perfection strawman and silly real life non-examples indicate otherwise) but here it is in a nutshell:

detecting and reacting to incidents is a useful thing (grsec has been probably doing it for longer and more efficiently than most) but this feature will not achieve anything, not just because there're so many ways to know when a kernel is equipped with it or because the potential for false positives, but also because in real life nobody reacts to logs on systems where script kiddies are considered an actual threat (these are the lowest value systems, cf. the kernel.org compromise whose dmesg with the sign of a backdoor laid in public for weeks before anyone figured out that something wasn't right with it). and where they're not a threat, the remaining attackers are sophisticated enough to use 0-day to begin with (many of which the mechanisms in grsec will handle unlike the proposed feature).

Known-exploit detection for the kernel

Posted Dec 20, 2013 10:52 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (1 responses)

The issue of ignoring alarms is a far more widespread one than can be covered in this thread, or indeed LWN at all.

In the maritime industry almost every other accident report will involve alarms that were disabled, non-functional, or ignored. In other transport industries it's less bad, but e.g. a London Underground driver overrode or disabled all the safety alarms in his train and was only alerted to the fact that he'd driven out of a station with the doors still open by the screaming of passengers. They couldn't alert him using the provided passenger alarm because he'd switched that off too.

Teaching people to investigate alarms rather than ignore them, and to test and maintain alarm systems so that they have confidence that the alarms reported are real is a bunch of work, but it's not impossible.

Known-exploit detection for the kernel

Posted Dec 24, 2013 6:34 UTC (Tue) by drag (guest, #31333) [Link]

The most critical step in that is to have alarms that are actually meaningful and functional.

In most of those cases you mentioned you'd find that those alarms were disabled because they had so many false positives. A alarm that goes off once because a train left it's doors open is useless when it also goes off a thousand times when the doors are actually closed.