Bugzilla – Bug 920170
VUL-0: CVE-2012-6689: kernel-source: incorrect validation of netlink message origin allows attackers to spoof netlink messages
Last modified: 2016-09-08 20:23:03 UTC
CVE-2012-6689 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=20e1db19db5d6b9e4e83021595eab0dc8f107bef netlink: fix possible spoofing from non-root processes Non-root user-space processes can send Netlink messages to other processes that are well-known for being subscribed to Netlink asynchronous notifications. This allows ilegitimate non-root process to send forged messages to Netlink subscribers. The userspace process usually verifies the legitimate origin in two ways: a) Socket credentials. If UID != 0, then the message comes from some ilegitimate process and the message needs to be dropped. b) Netlink portID. In general, portID == 0 means that the origin of the messages comes from the kernel. Thus, discarding any message not coming from the kernel. However, ctnetlink sets the portID in event messages that has been triggered by some user-space process, eg. conntrack utility. So other processes subscribed to ctnetlink events, eg. conntrackd, know that the event was triggered by some user-space action. Neither of the two ways to discard ilegitimate messages coming from non-root processes can help for ctnetlink. This patch adds capability validation in case that dst_pid is set in netlink_sendmsg(). This approach is aggressive since existing applications using any Netlink bus to deliver messages between two user-space processes will break. Note that the exception is NETLINK_USERSOCK, since it is reserved for netlink-to-netlink userspace communication. Still, if anyone wants that his Netlink bus allows netlink-to-netlink userspace, then they can set NL_NONROOT_SEND. However, by default, I don't think it makes sense to allow to use NETLINK_ROUTE to communicate two processes that are sending no matter what information that is not related to link/neighbouring/routing. They should be using NETLINK_USERSOCK instead for that. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Was fixed for Linux 3.6. Not affected. SLES 12, openSUSE * Affected potentially: SLES 11, 10
bugbot adjusting priority
(In reply to Marcus Meissner from comment #0) > This patch adds capability validation in case that dst_pid is set > in netlink_sendmsg(). This approach is aggressive since existing > applications using any Netlink bus to deliver messages between > two user-space processes will break. I guess this is something we can't fix in a released product. Also, it looks more like a bug in the receiving application if it trusts anything that comes over netlink to be from a root process. Is there a real threat, e.g. to conntrackd? Perhaps conntrackd could be hardened in some other way? This looks like a WONTFIX candidate, at least on the kernel side.
Sebastian, you know more about that ... can you help? Usually we have fixed the processes that receive netlink infos from the kernel? cannot make much sense of it
As it reads they are just making the patch for the conntrack tool as for some reason it cannot distinguish between kernel msg and faked msg as ctnetlink overlays this info by setting nlmsg_pid to the process that triggerd an event, even when its originated from kernel. (somewhat incorrect behavior, maybe better fixed it there?) So conntrackd (as they argue) has no way of knowing whether a netlink message is legit or not. And therefore they want to forbid users to send such messages in the first place, so no spoofing can happen. (I am not quite sure why their a) case cannot be used for checking or they use the source address passed along recvmsg() that also contains an nl_pid that should only be 0 if originated from kernel) However, this breaks the ABI, as non-root users cant send these messages any longer for their own IPC except setting NL_NONROOT_SEND (but I cant see where this can be set). Since this only affects ctnetlink, the impact should be quite limited (wrong flowinfo in conntrackd or so). Nevertheless, such fix is already upstream since quite some time. So it seems like new kernel semantics is that non-root users cannot send netlink msg anymore.
So we will leave out this hardening measure due to the ABI breakage and limited impact.
I will use this as note: CVE-2012-6689,20150520,NOTE:As this issue requires changing the kernel ABI on netlink reception checking, we currently have to leave out this patch. This issue does not affect SUSE Linux Enterprise 12 or newer products. can be adjusted if not fully correct