netdev - RE: [PATCH] tcp: md5: fix md5 RST when both sides have listener

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

Date:	Wed, 1 Feb 2012 02:48:21 -0500
From:	Shawn Lu <shawn.lu@...csson.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xiaoclu@...il.com" <xiaoclu@...il.com>
Subject: RE: [PATCH] tcp: md5: fix md5 RST when both sides have listener

Hi, Eric:

How about change the title and log to following:

  tcp: md5: RST: getting md5 key from listener

    TCP RST mechanism is broken in TCP md5(RFC2385). When
    connection is gone, md5 key is lost, sending RST
    without md5 hash is deem to ignored by peer. This can
    be a problem since RST help protocal like bgp to fast
    recove from peer crash.

    In most case, users of tcp md5, such as bgp and ldp,
    have listener on both side to accept connection from peer.
    md5 keys for peers are saved in listening socket.

    There are two cases in finding md5 key when connection is
    lost:
    1.Passive receive RST: The message is send to well known port,
    tcp will associate packet with listener. md5 key can be gotten
    from listener.

    2.Active receive RST (no sock): The message is send to ative
    side, there is no socket associated with message. In this case,
    finding listener from source port, then find md5 key from
    listener.

    we are not loosing sercuriy here:
    packet is checked with md5 hash. No RST is generated
    if md5 hash doesn't match or no md5 key can be found.

Note:
Will send out a new version that is on top of your new patch
-- "tcp: md5: protects md5sig_info with RCU"


-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@...il.com] 
Sent: Tuesday, January 31, 2012 9:09 PM
To: Shawn Lu
Cc: davem@...emloft.net; netdev@...r.kernel.org; xiaoclu@...il.com
Subject: Re: [PATCH] tcp: md5: fix md5 RST when both sides have listener

Le mardi 31 janvier 2012 à 15:53 -0800, Shawn Lu a écrit :
> TCP RST mechanism is broken in TCP md5(RFC2385). When connection is 
> gone, md5 key is lost, sending RST without md5 hash is deem to ignored 
> by peer. This can be a problem since RST help protocal like bgp to 
> fast recove from peer crash.
> 
> In most case, users of tcp md5, such as bgp and ldp, have listeners on 
> both sides. md5 keys for peers are saved in listening socket. When 
> passive side connection is gone, we can still get md5 key from 
> listening socket.
> When active side of connection is gone, we can try to find listening 
> socket through source port, and then md5 key.
> we are not loosing sercuriy here:
> packet is valified checked with md5 hash. No RST is generated if md5 
> hash doesn't match or no md5 key can be found.
> 
> Signed-off-by: Shawn Lu <shawn.lu@...csson.com>
> ---

Small notes : 

1) Always add [PATCH Vx] on your submission if it was a new version of a previous patch. (V2, V3, V4, ...)

If possible, add after the "---" separator an explanation of what changed in your new submission :

V3: added some rcu_read_lock()/rcu_read_unlock() sections

2) Also patch title and changelog are a bit confusing.

Only the machine receiving the TCP message and answering by RST message needs a listener, in case tcp frame cannot be associated to an existing tcp socket (ESTABLISHED or TIMEWAIT).

The other side doesnt need a listener, only a client using TCP MD5 option in its socket.

Other than that, your patch seems fine to me.

Acked-by: Eric Dumazet <eric.dumazet@...il.com>

Thanks !


--
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