• H
    [NETLINK]: Synchronous message processing. · 2a0a6ebe
    Herbert Xu 提交于
    Let's recap the problem.  The current asynchronous netlink kernel
    message processing is vulnerable to these attacks:
    
    1) Hit and run: Attacker sends one or more messages and then exits
    before they're processed.  This may confuse/disable the next netlink
    user that gets the netlink address of the attacker since it may
    receive the responses to the attacker's messages.
    
    Proposed solutions:
    
    a) Synchronous processing.
    b) Stream mode socket.
    c) Restrict/prohibit binding.
    
    2) Starvation: Because various netlink rcv functions were written
    to not return until all messages have been processed on a socket,
    it is possible for these functions to execute for an arbitrarily
    long period of time.  If this is successfully exploited it could
    also be used to hold rtnl forever.
    
    Proposed solutions:
    
    a) Synchronous processing.
    b) Stream mode socket.
    
    Firstly let's cross off solution c).  It only solves the first
    problem and it has user-visible impacts.  In particular, it'll
    break user space applications that expect to bind or communicate
    with specific netlink addresses (pid's).
    
    So we're left with a choice of synchronous processing versus
    SOCK_STREAM for netlink.
    
    For the moment I'm sticking with the synchronous approach as
    suggested by Alexey since it's simpler and I'd rather spend
    my time working on other things.
    
    However, it does have a number of deficiencies compared to the
    stream mode solution:
    
    1) User-space to user-space netlink communication is still vulnerable.
    
    2) Inefficient use of resources.  This is especially true for rtnetlink
    since the lock is shared with other users such as networking drivers.
    The latter could hold the rtnl while communicating with hardware which
    causes the rtnetlink user to wait when it could be doing other things.
    
    3) It is still possible to DoS all netlink users by flooding the kernel
    netlink receive queue.  The attacker simply fills the receive socket
    with a single netlink message that fills up the entire queue.  The
    attacker then continues to call sendmsg with the same message in a loop.
    
    Point 3) can be countered by retransmissions in user-space code, however
    it is pretty messy.
    
    In light of these problems (in particular, point 3), we should implement
    stream mode netlink at some point.  In the mean time, here is a patch
    that implements synchronous processing.  
    Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    2a0a6ebe
tcp_diag.c 18.6 KB