Message-ID: <CAGXu5jLghzKvLE0=ERQ10EZ_1GZ0642X6zr35EaSafq7WJ09Qw@mail.gmail.com>
Date:	Fri, 13 Dec 2013 10:07:35 -0800
From:	Kees Cook <keescook@...omium.org>
To:	"Theodore Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>,
	vegard.nossum@...cle.com, LKML <linux-kernel@...r.kernel.org>,
	Tommi Rantala <tt.rantala@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...capital.net>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Alan Cox <alan@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jason Wang <jasowang@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	James Morris <james.l.morris@...cle.com>
Subject: Re: [PATCH 1/9] Known exploit detection

On Thu, Dec 12, 2013 at 9:27 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>> > 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.
>
> Most organizations can't afford to have an in-house kernel team
> providing specialized kernels for their server farms or their
> customized desktop distributions.  :-)
>
> Some places have publically said that they do this; Google has
> publically talked about Goobuntu and their data center production
> kernels, and some financial firms on Wall Street have boasted about
> how they run with a customized kernel --- although other financial
> firms have said they don't want to do that because they don't want to
> void their support contract with Red Hat or SuSE.  I suspect that at
> most shopes, though, the latter is going to be far more common than
> the former.

We can never really know, but given the evidence I've seen, there are
a lot of custom kernels out in the world. That combined with the fact
that sloppy attackers will still probe distro kernels, I think the
argument that "attackers will fall back to other detection mechanisms"
isn't strong enough to convince me that this series lacks value.

> Practically speaking, testing for various distribution kernel
> versions, as well as specific ChromeOS and Android kernel versions,
> wouldn't be that difficult for an attacker, and would probably allow
> them to avoid detection for 99% of the Linux systems found in the
> wild.  It would certainly be useful for detecting attempted attacks
> for private kernels where the configuration and security patches
> applied for some internal kernel are not public --- and if that caused
> the botnet author to be paranoid enough to avoid attacking machines
> which didn't have a known distribution kernel that definitely had that
> vulnerability, it would certainly be good for people running their own
> privately maintained kernel image.  So if this increases the market
> demand for kernel programmers, that's a good thing, right?   :-)

The careful attackers can successfully probe a system without needing
uname at all. These patches won't help against them.

-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists