netdev - [SECURITY] Fix leaking of kernel heap addresses via /proc

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-next>] [day] [month] [year] [list]

Date:	Sat, 06 Nov 2010 16:11:47 -0400
From:	Dan Rosenberg <drosenberg@...curity.com>
To:	chas@....nrl.navy.mil, davem@...emloft.net, kuznet@....inr.ac.ru,
	pekkas@...core.fi, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, remi.denis-courmont@...ia.com
Cc:	netdev@...r.kernel.org, security@...nel.org
Subject: [SECURITY] Fix leaking of kernel heap addresses via /proc

Maintainers,

I am planning on submitting a series of patches to resolve the leakage
of kernel heap addresses to userspace via network protocol /proc
interfaces.  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.

Here's the list of protocols that I've identified as leaking socket
structure addresses via their /proc interfaces:

atm
ipv4
ipv6
key
netlink
packet
phonet
unix

There may be others, and I will continue looking for more examples, but
this is at least a good start.

Clearly, in most cases we cannot just remove the field from the /proc
output, as this would break a number of userspace programs that rely on
consistency.  However, I propose that we replace the address with a "0"
rather than leaking this information.

I'm writing this email before submitting a patch to ask if anyone would
have any objections to this change, and if anyone can foresee anything
breaking as a result of this.  Please let me know if you're on board,
have some doubts, or are totally opposed, and I can get this patch ready
for submission.

Thanks,
Dan Rosenberg

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html