Re: [PATCH 1/9] Known exploit detection

[Kees Cook]

On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@xxxxxxxxxx wrote:
>> From: Vegard Nossum <vegard.nossum@xxxxxxxxxx>
>>
>> The idea is simple -- since different kernel versions are vulnerable to
>> different root exploits, hackers most likely try multiple exploits before
>> they actually succeed.

I like this idea. It serves a few purposes, not the least of which is
very clearly marking in code where we've had problems, regardless of
the fact that it reports badness to the system owner. And I think
getting any additional notifications about bad behavior is a nice idea
too.

> Suppose we put put this into the mainstream kernel.  Wouldn't writers
> of root kit adapt by checking for the kernel version to avoid checking
> for exploits that are known not work?  So the question is whether the
> additional complexity in the kernel is going to be worth it, since
> once the attackers adapt, the benefits of trying to detect attacks for
> mitigated exploits will be minimal.

This is already somewhat the case, but I think this idea still has
value. The reality of the situation is that the kernels running on an
end-user's system is rarely a stock upstream kernel. As a result, they
usually have organization-specific versioning, which makes
version-only autodetection useless to an attacker. While it is
possible to keep track of all distro versions in a massive table, even
the public exploits rarely do this, instead focusing on maybe one or
two distros. But when attacking systems with kernels built custom by
various organizations that don't publish their kernel trees, it
becomes impossible to rely on just the version. Given all the forks,
and stable vs mainline, and backported patches vs not, the version
tends to only give a gross ball-park idea. Probing is still useful to
an attacker, and this proposes reporting those probes.

I like it. I like how lightweight it is, and I like that it can be
trivially compiled out. My concerns would be:

- how do we avoid bikeshedding about which exploits are "serious
enough" to trigger a report?

- who will keep adding these triggers going forward?

I'm more than happy to assist with adding future triggers, but I don't
want to be the only person doing it. :)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/