[lkml]   [2010]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking

* Willy Tarreau <> wrote:

> > An 'exploit honeypot' would be some small amount of 'detection' code for the
> > exploitable pattern of parameters (most attacks come via ioctls so we can add
> > detection for known holes without any performance hit), and the kernel would
> > warn the sysadmin that an exploit attempt has occured.
> If we pollute the ioctl code with all the CVEs we have accumulated over the years,
> I bet we'd get a performance hit and will probably introduce new bugs due to the
> harder to maintain code.

That's just wrong, because it's usually not the same ioctl hit with dozens of CVEs,
but lots of CVEs are spread out amongst lots of ioctls. You need to come up with
something more concrete than "I bet" to support that claim ;-)

> > The point is to make it riskier to run exploits - not to 'hide version because
> > we are so buggy'. Unprivileged attackers wont be able to know whether a kernel
> > is unpatched and wont know whether trying an actual exploit triggers a silent
> > alarm or not.
> In my opinion, hiding the distro-specific part of the version should not cause too
> much harm, but still I find this useless.
> You see, I've used the vmsplice exploit at one place. Do you know how I did ? $
> cat /etc/redhat-release
> Then I opened the box and installed the DVD showing the same version on a spare PC
> to experiment with it. Once I got the exploit to reliably work without crashing
> the kernel nor leaving traces, I dared launching it on the target machine and it
> worked. Uname -r was not involved there. [...]

Sigh, you _still_ have not understood my point and you clearly dont seem to know how
honeypots work.

An 'exploit honeypot' kernel feature, on a patched kernel, would at that point warn
the admin that local user XXX tried to run an exploit.

The point is that the attacker cannot know whether it's safe to run the exploit on
the box (will result in a compromise), or is not safe to run the exploit (the
honeypot code will warn the admin).

Uname -r fuzzing is not needed because the attacker 'needs to run it' to compromise
a vulnerable system (as you seem to believe). It's done because if the attacker runs
it on a _not vulnerable machine_, it keeps him from running the exploit.

In short, it removes the 'is it safe to try this exploit' information from the
system - and if there's also a honeypot there, it introduces a real (and if done
well enough, undetectable) risk of detection for the attacker.



 \ /
  Last update: 2010-11-07 10:07    [W:0.094 / U:5.908 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site