netdev - Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/

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]

Message-ID: <1289546610.17691.1770.camel@edumazet-laptop>
Date:	Fri, 12 Nov 2010 08:23:30 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Dan Rosenberg <drosenberg@...curity.com>
Cc:	David Miller <davem@...emloft.net>, socketcan@...tkopp.net,
	kuznet@....inr.ac.ru, urs.thuermann@...kswagen.de,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net, jmorris@...ei.org,
	remi.denis-courmont@...ia.com, pekkas@...core.fi, sri@...ibm.com,
	vladislav.yasevich@...com, tj@...nel.org, lizf@...fujitsu.com,
	joe@...ches.com, shemminger@...tta.com, hadi@...atatu.com,
	ebiederm@...ssion.com, adobriyan@...il.com, jpirko@...hat.com,
	johannes.berg@...el.com, daniel.lezcano@...e.fr, xemul@...nvz.org,
	socketcan-core@...ts.berlios.de, netdev@...r.kernel.org,
	linux-sctp@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/

Le jeudi 11 novembre 2010 à 21:34 -0500, Dan Rosenberg a écrit :
> > I want whatever you replace it with to be equivalent for
> > object tracking purposes.
> 
> In nearly all of the cases I fixed, the socket inode is already
> provided, which serves as a perfectly good unique identifier.  Would you
> prefer I include that information twice?

Oh well. Please read this answer carefuly.

Some facts to feed your next patch. I am very pleased you changed your
mind and that we keep useful information in kernel log.

1) Inode numbers are not guaranteed to be unique. Its a 32bit seq
number, and we dont check another socket inode use the same inode number
(after 2^32 allocations it can happens)

2) /proc/net/ files can deliver same "line" of information several
times, because of their implementation.

3) Because of SLAB_DESTROY_BY_RCU, same 'kernel socket pointer' can be
seen several times in /proc/net/tcp & /proc/net/udp, but really on
different "sockets"

4) Some good applications use both the socket pointer and inode number
(tuple) to filter out the [2] problem. Dont break them, please ?
Anything that might break an application must be at the very least
tunable.

In my opinion, a good thing would be :

- Use a special printf() format , aka "secure pointer", as Thomas
suggested.

- Make sure you print different opaque values for two different kernel
pointers. This is mandatory.

- Make sure the NULL pointer stay as a NULL pointer to not let the
hostile user know your secret, and to ease debugging stuff.

- Have security experts advice to chose a nice crypto function, maybe
jenkin hash. Not too slow would be nice.

static unsigned long securize_kpointers_rnd;

At boot time, stick a random value in this variable.
(Maybe make sure the 5 low order bits are 0)

unsigned long opacify_kptr(unsigned long ptr)
{
	if (ptr == 0)
		return ptr;
	if (capable(CAP_NET_ADMIN))
		return ptr;

	return some_crypto_hash(ptr, &securize_kpointers_rnd);
}

At least, use a central point, so that we can easily add/change the
logic if needed.

Please provide this patch in kernel/printk.c for initial review, then
once everybody is OK, you can send one patch for net tree.

No need to send 10 patches if we dont agree on the general principle.

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