[lkml]   [2013]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/9] Known exploit detection
On Thu, Dec 12, 2013 at 3:50 PM, Ryan Mallon <> wrote:
> On 13/12/13 08:13, Kees Cook wrote:
>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <> wrote:
>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, wrote:
>>>> From: Vegard Nossum <>
>>>> 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. Since running through a
> series of exploits is pretty quick, this can probably all be done before
> the sysadmin ever notices.

Sure, but many organizations have centralized network syslog, so
unless the attack can spread to those machines too (which are usually
more locked down), the attacker will leave traces.

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

Totally true, but there's a million way to DoS a local machine. At
least this way shows who's doing it. It's the DoSes that don't include
attribution that I worry about. :)


Kees Cook
Chrome OS Security

 \ /
  Last update: 2013-12-13 04:21    [W:0.149 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site