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: <20101112.123738.179940542.davem@davemloft.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ