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
| ||
|
Message-ID: <ygfwroodclp.fsf@janus.isnogud.escape.de> 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
Powered by blists - more mailing lists