Date:	Sat, 14 Dec 2013 10:07:03 +1100
From:	Ryan Mallon <rmallon@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Kees Cook <keescook@...omium.org>, Theodore Ts'o <tytso@....edu>,
	vegard.nossum@...cle.com, LKML <linux-kernel@...r.kernel.org>,
	Tommi Rantala <tt.rantala@...il.com>,
	"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 14/12/13 00:06, Ingo Molnar wrote:

> 
> * Ryan Mallon <rmallon@...il.com> wrote:
> 
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@....edu> wrote:
>>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@...cle.com wrote:
>>>>> From: Vegard Nossum <vegard.nossum@...cle.com>
>>>>>
>>>>> 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.
>>
>> Though, if an attacker is running through a series of exploits, and 
>> one eventually succeeds then the first thing to do would be to clean 
>> traces of the _exploit() notifications from the syslog. [...]
> 
> There are several solutions to that:
> 
> 1)
> 
> Critical sites use remote logging over a fast LAN, so a successful 
> exploit would have to zap the remote logging daemon pretty quickly 
> before the log message goes out over the network.
> 
> 2)
> 
> Some sites also log to append-only media [such as a printer] or other 
> append-only storage interfaces - which cannot be manipulated from the 
> attacked system alone after a successful break-in.
> 
> 3)
> 
> In future the exploit() code could trigger actual active defensive 
> measures, such as immediately freezing all tasks of that UID and 
> blocking further fork()s/exec()s of that UID.
> 
> Depending on how critical the security of the system is, such active 
> measures might still be a preferable outcome even if there's a chance 
> of false positives. (Such active measures that freeze the UID will 
> also help with forensics, if the attack is indeed real.)
> 
>> [...] Since running through a series of exploits is pretty quick, 
>> this can probably all be done before the sysadmin ever notices.
> 
> It's not necessarily the sysadmin the attacker is racing against, but 
> against append-only logging and other defensive measures - which too 
> are programs.
> 
>> The _exploit() notifications could also be used to spam the syslogs. 
>> Although they are individually ratelimited, if there are enough 
>> _exploit() markers in the kernel then an annoying person can cycle 
>> through them all to generate large amounts of useless syslog.
> 
> AFAICS they are globally rate-limited, just like many other 
> attacker-triggerable printk()s the kernel may generate.


Actually, that opens another possibility for an attacker. Since they
know the logging is rate-limited, they can first attempt a low risk
CVE (or one that is known to have false positives, see comments from
others about dumb user-space/corrupted file-systems, etc). So that
attempt gets logged, and possibly ignored, but then more attempts
can be quickly made that will not be logged.

Of course, if you have some policy that kicks the user or some such 
then that would limit this approach, but just rate-limited logging
by itself might not be enough. The problem with policy based 
solutions, though, is that if the attacker knows what the policy
is then they can game it. E.g. don't bother trying the known exploits
which will immediately get you kicked; add sufficient delay between
attempts, etc.

~Ryan
 



--
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