Bug 920170 - (CVE-2012-6689) VUL-0: CVE-2012-6689: kernel-source: incorrect validation of netlink message origin allows attackers to spoof netlink messages
VUL-0: CVE-2012-6689: kernel-source: incorrect validation of netlink message ...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Jiri Bohac
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2015-03-02 09:47 UTC by Marcus Meissner
Modified: 2016-09-08 20:23 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2015-03-02 09:47:22 UTC


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>
Comment 1 Marcus Meissner 2015-03-02 09:48:24 UTC
Was fixed for Linux 3.6.

Not affected. SLES 12, openSUSE *

Affected potentially: SLES 11, 10
Comment 2 Swamp Workflow Management 2015-03-02 23:00:34 UTC
bugbot adjusting priority
Comment 3 Jiri Bohac 2015-05-15 12:09:45 UTC
(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.
Comment 4 Marcus Meissner 2015-05-18 14:37:41 UTC
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
Comment 5 Sebastian Krahmer 2015-05-19 12:33:04 UTC
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.
Comment 7 Marcus Meissner 2015-05-20 11:28:46 UTC
So we will leave out this hardening measure due to the ABI breakage and limited impact.
Comment 8 Marcus Meissner 2015-05-20 11:32:19 UTC
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