netdev - Re: [PATCH 0/9] 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]

Date:	07 Nov 2010 22:53:54 +0100
From:	Urs Thuermann <urs@...ogud.escape.de>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Dan Rosenberg <drosenberg@...curity.com>, 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, netdev@...r.kernel.org,
	security@...nel.org, stable@...nel.org
Subject: Re: [PATCH 0/9] Fix leaking of kernel heap addresses in net/

Eric Dumazet <eric.dumazet@...il.com> writes:

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

dmesg and syslog aren't the only problem.  There are files in
/proc/net/ that must be readable by all users in order for a number of
tools to work, e.g. netstat(8), and those files contain kernel
addresses of sock structs.

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

Simple XOR with a secret constant doesn't help very much.  Many bits
of that hidden constant can be revealed quite easily.  On x86-32 for
example all addresses are in the high 1 GB address space so the
highest two address bits are 1.  Many structs of type sock are aligned
to 64 or higher powers of two so you can easily infer the lower 6 or
more bits of that hidden XOR constant.  If you know two structs of
alignment 2^n are contiguous in memory you can infer the lower n+1
bits.

I suggest either one of the following two solutions:

1. Make the contents of the proc-files in question dependent on some
   capability, e.g. CAP_SYS_ADMIN or some new CAP_KERNEL_DEBUG.  If
   the process opening the file owns that capability it will see the
   kernel address, otherwise it will see 0.

2. Replace the kernel address by the socket inode number or some other
   identifying value (as our patch for CAN does) and provide some
   mechanism for root only to translate that value to the
   corresponding kernel address.

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