linux-kernel - Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 7 Nov 2010 10:03:37 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Willy Tarreau <w@....eu>
Cc:	Marcus Meissner <meissner@...e.de>, security@...nel.org,
	mort@....com, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	fweisbec@...il.com, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, jason.wessel@...driver.com,
	tj@...nel.org, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to
 reduce ease of attacking

* Willy Tarreau <w@....eu> 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.

Thanks,

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