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]

Date:	Fri, 12 Nov 2010 12:37:38 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	adobriyan@...il.com
Cc:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/

From: Alexey Dobriyan <adobriyan@...il.com>
Date: Fri, 12 Nov 2010 22:18:50 +0200

> On Fri, Nov 12, 2010 at 08:33:15AM -0800, Stephen Hemminger wrote:
>> Also, the whole idea needs to be under a config option, so only
>> the paranoid idiots turn it on.
> 
> Would be fun if something will break because ffff8800bcd498c0
> will become something else. :-)

Actually, this is not even a joke.

Take a look at how we track what sockets a user wants dumped via
the inet_diag netlink facility, the socket pointer is used as
the identification cookie.

I'm sure we'll now get some more security theatre about how we
have to undo that too.

More and more I see this whole idea as extremely rediculious.

If I can write to or read kernel memory, I can look up the
sockets, inodes, and whatever else we're currently exposing
the addresses of.  Even without a symbol table, which is
readily available, I can easily find the ksymtab and find the
inode and socket hash table addresses there.

This whole exercise is closing the barn door after the horses have
already escaped, and it's causing all kinds of inconveniences
that we really have no need for.
--
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