Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751705AbaKUSzQ (ORCPT ); Fri, 21 Nov 2014 13:55:16 -0500 Received: from mail-oi0-f47.google.com ([209.85.218.47]:42722 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751080AbaKUSzN (ORCPT ); Fri, 21 Nov 2014 13:55:13 -0500 MIME-Version: 1.0 In-Reply-To: <1416524993-26228-1-git-send-email-calvinowens@fb.com> References: <1416524993-26228-1-git-send-email-calvinowens@fb.com> Date: Fri, 21 Nov 2014 13:55:12 -0500 Message-ID: Subject: Re: [PATCH] tcp: Restore RFC5961-compliant behavior for SYN packets From: Neal Cardwell To: Calvin Owens Cc: "David S. Miller" , Alexey Kuznetsov , James Morris , Eric Dumazet , kernel-team@fb.com, Netdev , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 20, 2014 at 6:09 PM, Calvin Owens wrote: > Commit c3ae62af8e755 ("tcp: should drop incoming frames without ACK > flag set") was created to mitigate a security vulnerability in which a > local attacker is able to inject data into locally-opened sockets by > using TCP protocol statistics in procfs to quickly find the correct > sequence number. > > This broke the RFC5961 requirement to send a challenge ACK in response > to spurious RST packets, which was subsequently fixed by commit > 7b514a886ba50 ("tcp: accept RST without ACK flag"). > > Unfortunately, the RFC5961 requirement that spurious SYN packets be > handled in a similar manner remains broken. > > RFC5961 section 4 states that: > > ... the handling of the SYN in the synchronized state SHOULD be > performed as follows: > > 1) If the SYN bit is set, irrespective of the sequence number, TCP > MUST send an ACK (also referred to as challenge ACK) to the remote > peer: > > > > After sending the acknowledgment, TCP MUST drop the unacceptable > segment and stop processing further. > > By sending an ACK, the remote peer is challenged to confirm the loss > of the previous connection and the request to start a new connection. > A legitimate peer, after restart, would not have a TCB in the > synchronized state. Thus, when the ACK arrives, the peer should send > a RST segment back with the sequence number derived from the ACK > field that caused the RST. > > This RST will confirm that the remote peer has indeed closed the > previous connection. Upon receipt of a valid RST, the local TCP > endpoint MUST terminate its connection. The local TCP endpoint > should then rely on SYN retransmission from the remote end to > re-establish the connection. > > This patch lets SYN packets through the discard added in c3ae62af8e755, > so that spurious SYN packets are properly dealt with as per the RFC. > > The challenge ACK is sent unconditionally and is rate-limited, so the > original vulnerability is not reintroduced by this patch. > > Signed-off-by: Calvin Owens Acked-by: Neal Cardwell neal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/