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>] [day] [month] [year] [list]

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