Known-exploit detection for the kernel

Posted Dec 19, 2013 0:49 UTC (Thu) by ncm (guest, #165)
In reply to: Known-exploit detection for the kernel by spender
Parent article: Known-exploit detection for the kernel

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