public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Ingo Molnar <mingo@elte.hu>
Cc: Marcus Meissner <meissner@suse.de>,
	security@kernel.org, mort@sgi.com,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	fweisbec@gmail.com, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, jason.wessel@windriver.com,
	tj@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking
Date: Sun, 7 Nov 2010 13:51:20 +0100	[thread overview]
Message-ID: <20101107125120.GA4627@1wt.eu> (raw)
In-Reply-To: <20101107123232.GB6512@elte.hu>

On Sun, Nov 07, 2010 at 01:32:32PM +0100, Ingo Molnar wrote:
> No. The 'exploit honeypot' mechanism i outlined is really simple, and it means what 
> i explained already:
> 
>  - attacker breaks into unprivileged user-space
> 
>  - attacker runs exploit
> 
>  - exploit attempt gets detected by the 'exploit honeypot' kernel code and a 
>    (silent) warning goes to the admin (via a syslog message for example)
> 
>  - attacker only sees that the attack did not succeed
> 
> This makes it _unsafe_ (for many types of attackers) to run an exploit locally.

It's already unsafe and has always been. When running local kernel exploits,
it's common to find lots of segfault traces in dmesg. It's common to hang the
machine (the vmsplice exploit had a 50% failure rate from my tests).

> > That's not much different than trying to fire the exploit itself. [...]
> 
> Erm, the difference is possible _detection_ via a silent alarm.
>
> There's a huge difference between 'attempting an exploit and being caught' and 'not 
> even trying the exploit because based on the kernel version the attacker knows it 
> wont work'.

And there's an even bigger difference between leaving traces of a failed
exploit attempt and successfully getting the exploit to work because the
system is not updated in time. That's been my point since the beginning,
most kernel exploits are run very early when released to the public. So
that's when a simple "uptime" will tell you it's safe to run your exploit.
And if you want to hide the uptime, let's simply check the creation date
of /dev/shm, or that a file you left in /tmp has not been removed by the
admin's scripts which clean that up at boot, etc...

In my opinion this is not efficient at all. Also, I've already been involved
in post-mortem diags on compromised machines. If the intruder is not a known
local user, he does not care at all being caught. Leaving rootkits everywhere
is generally not a problem for them, some don't even take care of clearing
the logs, because they bounced from already compromised systems.

Willy


  reply	other threads:[~2010-11-07 12:52 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-04 10:09 [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking Marcus Meissner
2010-11-04 10:11 ` Tejun Heo
2010-11-05  0:11   ` [Security] " Eugene Teo
2010-11-04 11:46 ` Ingo Molnar
2010-11-04 12:29   ` Marcus Meissner
2010-11-04 13:58     ` Ingo Molnar
2010-11-04 14:11       ` Ingo Molnar
2010-11-04 14:33         ` Marcus Meissner
2010-11-04 14:38           ` Tejun Heo
2010-11-04 14:43             ` H. Peter Anvin
2010-11-04 14:48               ` Tejun Heo
2010-11-04 19:08           ` Ingo Molnar
2010-11-04 21:29             ` [Security] " Willy Tarreau
2010-11-04 21:51               ` Ingo Molnar
2010-11-04 22:35                 ` Willy Tarreau
2010-11-04 23:46                   ` Willy Tarreau
2010-11-07  8:50                   ` Ingo Molnar
2010-11-07  9:08                     ` Ingo Molnar
2010-11-07  9:49                     ` Willy Tarreau
2010-11-07 11:27                       ` Ingo Molnar
2010-11-07 11:41                         ` Willy Tarreau
2010-11-07 11:47                           ` Ingo Molnar
2010-11-07 11:56                             ` Willy Tarreau
2010-11-07 12:12                               ` Ingo Molnar
2010-11-07 12:22                                 ` Willy Tarreau
2010-11-07 12:25                                   ` Ingo Molnar
2010-11-07 12:39                                     ` Willy Tarreau
2010-11-07 12:32                                   ` Ingo Molnar
2010-11-07 12:51                                     ` Willy Tarreau [this message]
2010-11-07 15:27                                     ` Alan Cox
2010-11-08  6:29                                       ` Ingo Molnar
2010-11-07 11:42                       ` Ingo Molnar
2010-11-07 11:51                         ` Willy Tarreau
2010-11-07 12:37                           ` Ingo Molnar
2010-11-07 12:55                             ` Willy Tarreau
2010-11-07  8:56                   ` Ingo Molnar
2010-11-07  9:03                   ` Ingo Molnar
     [not found]               ` <20101104215157.GA25128@ <20101107090805.GA27983@elte.hu>
2010-11-13 13:06                 ` Gilles Espinasse
2010-11-07 18:02           ` Andi Kleen
2010-11-07 18:32             ` H. Peter Anvin
2010-11-10  8:53               ` Ingo Molnar
2010-11-11  2:51                 ` H. Peter Anvin
2010-11-11  7:05                   ` Ingo Molnar
2010-11-05  2:38     ` Frank Rowand
2010-11-10 20:58       ` Jesper Juhl
2010-11-05  0:20 ` Jesper Juhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101107125120.GA4627@1wt.eu \
    --to=w@1wt.eu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=meissner@suse.de \
    --cc=mingo@elte.hu \
    --cc=mort@sgi.com \
    --cc=security@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox