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: <1289673754.3090.362.camel@Dan> Date: Sat, 13 Nov 2010 13:42:34 -0500 From: Dan Rosenberg <drosenberg@...curity.com> To: davem@...emloft.net Cc: netdev@...r.kernel.org Subject: Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/ > 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. Of course if you can both write and read to kernel memory, this is a pointless exercise, but those are not the conditions I am trying to defend against. Proactive security assumes that individual bugs will continue to be found, and takes steps to prevent exploitation of classes of bugs on a broader scale. In this case, the goal is for it to be difficult to exploit arbitrary write bugs WITHOUT having a separate arbitrary read bug. Several other steps are being taken in this direction - there is open discussion about the merits of hiding symbol information, address space randomization, marking various likely targets as read-only, and restricting access to debugging information. However, none of this really accomplishes much if addresses are still exposed via /proc. I'm sorry that you see all this as "security theatre". It's clear that there's too much resistance to this effort for it to ever succeed, so I'm ceasing attempts to get this patch series through. -Dan -- 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