Re: [PATCH 0/9] Fix leaking of kernel heap addresses in net/

[Eric Dumazet <eric.dumazet@gmail.com>]

Le dimanche 07 novembre 2010 à 11:31 -0500, Dan Rosenberg a écrit :
> This patch series resolves the leakage of kernel heap addresses to
> userspace via network protocol /proc interfaces and public error
> messages.  Revealing this information is a bad idea from a security
> perspective for a number of reasons, the most obvious of which is it
> provides unprivileged users a mechanism by which to create a structure
> in the kernel heap containing function pointers, obtain the address of
> that structure, and overwrite those function pointers by leveraging
> other vulnerabilities.  It is my hope that by eliminating this
> information leakage, in conjunction with making statically-declared
> function pointer tables read-only (to be done in a separate patch
> series), we can at least add a small hurdle for the exploitation of a
> subset of kernel vulnerabilities.
> 
> To maintain compatibility with userspace programs relying on
> consistent /proc output, the output descriptions and number of fields
> are not changed.  When a unique identifier for the socket is desired,
> the socket address has been replaced with the socket inode number.  When
> the inode number is already present in the output, the address has been
> replaced with a 0.  In these cases, the format specifier has been
> changed to %d, because a %p output of 0 from kernel space is written as
> "(null)", while userspace %p can only parse "(nil)".
> 

NACK

Thats a pretty stupid patch series, sorry.

You are basically ruining a lot of debugging facilities we use every day
to find and fix _real_ bugs. The bugs that happen to crash machines of
our customers.

If you want to avoid a user reading kernel syslog, why dont you fix the
problem for non root users able to "dmesg" ? I personally dont care.

I am a root user on my machine, I _want_ to have some pretty basic
informations so that I can work on it, and I believe my work is useful.

There are pretty easy ways to not disclose "information", but your way
of using '0' for all values is the dumbest idea one could ever had.

A single XOR with a "root only visible, random value chosen at boot"
would be OK. At least we could continue our work, with litle burden.