| Message ID | 20130207175240.GA12520@www.outflux.net |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
Sorry I'm not applying this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 7 Feb 2013 09:52:40 -0800 Kees Cook <keescook@chromium.org> wrote: > This is based on Willy Tarreau's patch from 2008[1]. The goal is to > close a corner-case of TCP that isn't used and poses a small DoS risk. > For systems that do not want to take any risk at all, this is a desirable > configuration knob. > > It is possible for two clients to connect with crossed SYNs without > checking sequence numbers. As such, it might be possible to guess a source > port number to block a system from making connections to well-known > ports and IP addresses (e.g. auto-update checks) without requiring a > MiTM position. > This patch probably also breaks TCP STUNT that is used by some applications for NAT traversal. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 7, 2013 at 10:39 AM, Stephen Hemminger <stephen@networkplumber.org> wrote: > On Thu, 7 Feb 2013 09:52:40 -0800 > Kees Cook <keescook@chromium.org> wrote: > >> This is based on Willy Tarreau's patch from 2008[1]. The goal is to >> close a corner-case of TCP that isn't used and poses a small DoS risk. >> For systems that do not want to take any risk at all, this is a desirable >> configuration knob. >> >> It is possible for two clients to connect with crossed SYNs without >> checking sequence numbers. As such, it might be possible to guess a source >> port number to block a system from making connections to well-known >> ports and IP addresses (e.g. auto-update checks) without requiring a >> MiTM position. >> > > This patch probably also breaks TCP STUNT that is used by some applications for NAT > traversal. The patch would not break it -- it defaults the sysctl to staying enabled. If you mean the documentation should be updated, sure, that's easy to do. David: I know you aren't a fan of this patch, but I'd like to try to convince you. :) This leaves the feature enabled and add a toggle for systems (like Chrome OS) that don't want to risk this DoS at all. There are so very many other toggle, I don't see why this one would be a problem to add. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/07/2013 10:44 AM, Kees Cook wrote: >> >> This patch probably also breaks TCP STUNT that is used by some applications for NAT >> traversal. > > The patch would not break it -- it defaults the sysctl to staying enabled. > > If you mean the documentation should be updated, sure, that's easy to do. > > David: I know you aren't a fan of this patch, but I'd like to try to > convince you. :) This leaves the feature enabled and add a toggle for > systems (like Chrome OS) that don't want to risk this DoS at all. > There are so very many other toggle, I don't see why this one would be > a problem to add. > It is not just STUNT, but in NAT-less configurations behind stateful firewalls (which is expected to be the norm for IPv6), TCP rendezvous via crossed SYN is a very effective way to establish peer-to-peer connections. -hpa -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Kees Cook <keescook@chromium.org> Date: Thu, 7 Feb 2013 10:44:02 -0800 > David: I know you aren't a fan of this patch, but I'd like to try to > convince you. :) This leaves the feature enabled and add a toggle for > systems (like Chrome OS) that don't want to risk this DoS at all. > There are so very many other toggle, I don't see why this one would be > a problem to add. We're not in the business of allowing the changing of the TCP state machine behavior like this. Sorry. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kees Cook <keescook@chromium.org> writes: > The patch would not break it -- it defaults the sysctl to staying enabled. > > If you mean the documentation should be updated, sure, that's easy to do. > > David: I know you aren't a fan of this patch, but I'd like to try to > convince you. :) This leaves the feature enabled and add a toggle for > systems (like Chrome OS) that don't want to risk this DoS at all. > There are so very many other toggle, I don't see why this one would be > a problem to add. Chrome OS has no plans to implement webrtc? Last I had read that support had been added to the release versions of Chrome, and was in the development builds of firefox. I really don't belive that there are many systems that don't intend to run a web browser. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Kees Cook <keescook@chromium.org> writes: > >> The patch would not break it -- it defaults the sysctl to staying enabled. >> >> If you mean the documentation should be updated, sure, that's easy to do. >> >> David: I know you aren't a fan of this patch, but I'd like to try to >> convince you. :) This leaves the feature enabled and add a toggle for >> systems (like Chrome OS) that don't want to risk this DoS at all. >> There are so very many other toggle, I don't see why this one would be >> a problem to add. > > Chrome OS has no plans to implement webrtc? Last I had read that > support had been added to the release versions of Chrome, and was in the > development builds of firefox. I really don't belive that there are > many systems that don't intend to run a web browser. I haven't looked at the internals of webrtc. Are you implying some feature in it relies on the TCP simultaneous connect? -Kees
Kees Cook <keescook@chromium.org> writes: > On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman > <ebiederm@xmission.com> wrote: >> Kees Cook <keescook@chromium.org> writes: >> >>> The patch would not break it -- it defaults the sysctl to staying enabled. >>> >>> If you mean the documentation should be updated, sure, that's easy to do. >>> >>> David: I know you aren't a fan of this patch, but I'd like to try to >>> convince you. :) This leaves the feature enabled and add a toggle for >>> systems (like Chrome OS) that don't want to risk this DoS at all. >>> There are so very many other toggle, I don't see why this one would be >>> a problem to add. >> >> Chrome OS has no plans to implement webrtc? Last I had read that >> support had been added to the release versions of Chrome, and was in the >> development builds of firefox. I really don't belive that there are >> many systems that don't intend to run a web browser. > > I haven't looked at the internals of webrtc. Are you implying some > feature in it relies on the TCP simultaneous connect? I am saying that yes. webrtc is built on ICE (interactivity connectivity establishment). ICE support for TCP (RFC6544) uses TCP simultaneous connect. webrtc supports tcp connections. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Eric, On Thu, Feb 14, 2013 at 11:10:46PM -0800, Eric W. Biederman wrote: > Kees Cook <keescook@chromium.org> writes: > > > On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman > > <ebiederm@xmission.com> wrote: > >> Kees Cook <keescook@chromium.org> writes: > >> > >>> The patch would not break it -- it defaults the sysctl to staying enabled. > >>> > >>> If you mean the documentation should be updated, sure, that's easy to do. > >>> > >>> David: I know you aren't a fan of this patch, but I'd like to try to > >>> convince you. :) This leaves the feature enabled and add a toggle for > >>> systems (like Chrome OS) that don't want to risk this DoS at all. > >>> There are so very many other toggle, I don't see why this one would be > >>> a problem to add. > >> > >> Chrome OS has no plans to implement webrtc? Last I had read that > >> support had been added to the release versions of Chrome, and was in the > >> development builds of firefox. I really don't belive that there are > >> many systems that don't intend to run a web browser. > > > > I haven't looked at the internals of webrtc. Are you implying some > > feature in it relies on the TCP simultaneous connect? > > I am saying that yes. > > webrtc is built on ICE (interactivity connectivity establishment). ICE > support for TCP (RFC6544) uses TCP simultaneous connect. webrtc > supports tcp connections. Then I suspect that a large number of firewalls will need updates after significant rework for this proposal to succeed. I'm not saying this will not eventually happen, but there are significant risks associated with this feature. Netfilter had this in the window tracking patches around 2002-2003 and this had to be reverted because a client was able to establish complete connections by sending SYN-SYN/ACK-ACK itself. Other products will fall through these cracks. And last but not least, it's the only behaviour in TCP which allows a random attacker to prevent a connection from establishing by guessing only a 16-bit port, regardless of any sequence number. Considering how we've been bothered by people who considered that our sequence numbers were not random enough, I already expect that the absolute lack of need of a sequence number will bring new funny articles. Back then, I did a PoC which permanently prevented an anti-virus proxy from establishing any connection to its update server, and it did not require a lot of traffic obviously. People running such proxies probably don't need webrtc with its assorted lot of issues. I'm not advocating for pushing the patch, I understand it's not desired. I just want to ensure that people understand what simultaneous connect means in terms of DoS for a feature which is rarely used and rarely technically possible at all. Regards, Willy -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Willy Tarreau <w@1wt.eu> writes: > Hi Eric, > > On Thu, Feb 14, 2013 at 11:10:46PM -0800, Eric W. Biederman wrote: >> Kees Cook <keescook@chromium.org> writes: >> >> > On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman >> > <ebiederm@xmission.com> wrote: >> >> Kees Cook <keescook@chromium.org> writes: >> >> >> >>> The patch would not break it -- it defaults the sysctl to staying enabled. >> >>> >> >>> If you mean the documentation should be updated, sure, that's easy to do. >> >>> >> >>> David: I know you aren't a fan of this patch, but I'd like to try to >> >>> convince you. :) This leaves the feature enabled and add a toggle for >> >>> systems (like Chrome OS) that don't want to risk this DoS at all. >> >>> There are so very many other toggle, I don't see why this one would be >> >>> a problem to add. >> >> >> >> Chrome OS has no plans to implement webrtc? Last I had read that >> >> support had been added to the release versions of Chrome, and was in the >> >> development builds of firefox. I really don't belive that there are >> >> many systems that don't intend to run a web browser. >> > >> > I haven't looked at the internals of webrtc. Are you implying some >> > feature in it relies on the TCP simultaneous connect? >> >> I am saying that yes. >> >> webrtc is built on ICE (interactivity connectivity establishment). ICE >> support for TCP (RFC6544) uses TCP simultaneous connect. webrtc >> supports tcp connections. > > Then I suspect that a large number of firewalls will need updates after > significant rework for this proposal to succeed. Not at all. ICE is about trying different ways to get two machines talking and using what works, and UDP connections are the primary. > I'm not saying this will > not eventually happen, but there are significant risks associated with > this feature. Netfilter had this in the window tracking patches around > 2002-2003 and this had to be reverted because a client was able to establish > complete connections by sending SYN-SYN/ACK-ACK itself. Other products will > fall through these cracks. Interesting. It works for me here on 3.8. I was able to get two machines to perform a simultaneous TCP open and successfully pass each other a message. Between those two machines were to NAT routers use conntrack ip masquerading. Those two NAT routers were connected by a third router that just routed their between their public addresses. Well strictly speaking they were network namespaces created with ip netns add .. and connected by veth tunnels, but it still worked and it definitely exercised the proper code paths. > And last but not least, it's the only behaviour in TCP which allows a > random attacker to prevent a connection from establishing by guessing > only a 16-bit port, regardless of any sequence number. Considering how > we've been bothered by people who considered that our sequence numbers > were not random enough, I already expect that the absolute lack of need > of a sequence number will bring new funny articles. I don't quite understand the DOS potential. Is the problem the attacker makes it look like a different connection has already suceeded so that legitimate connections get a RST? I'm not clear how that differs in practice in DoS potential from simply spoofing a SYN to a listening port. > Back then, I did a PoC which permanently prevented an anti-virus proxy > from establishing any connection to its update server, and it did not > require a lot of traffic obviously. People running such proxies probably > don't need webrtc with its assorted lot of issues. > > I'm not advocating for pushing the patch, I understand it's not desired. > I just want to ensure that people understand what simultaneous connect > means in terms of DoS for a feature which is rarely used and rarely > technically possible at all. When the STUNT folks measured the TCP simultaneous open feasiblity back in 2005 they measured an average 88% success rate in estabilishing TCP peer connections in the wild. So unless something has changed drastically (or their mesasurements were wildly inaccurate) it technically feasible a very interesting percentage of the time. Beyond that it is a sufficiently common trick for establishing peer to peer communications that an RFC has been written allowing peer to peer code written by different authors to interoperate. I just want to make it clear that for a lot of interesting cases TCP simultaneous open works today and is very interesting for getting client machines talking directly to each other. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Eric, On Fri, Feb 15, 2013 at 02:31:27AM -0800, Eric W. Biederman wrote: > > I'm not saying this will > > not eventually happen, but there are significant risks associated with > > this feature. Netfilter had this in the window tracking patches around > > 2002-2003 and this had to be reverted because a client was able to establish > > complete connections by sending SYN-SYN/ACK-ACK itself. Other products will > > fall through these cracks. > > Interesting. It works for me here on 3.8. > > I was able to get two machines to perform a simultaneous TCP open and > successfully pass each other a message. I'm not surprized, I've been doing demos of this that using netcat as well. > Between those two machines were to NAT routers use conntrack ip > masquerading. If these NAT routers were recent enough linux kernels, that should work as last I checked, this was reintroduced differently in netfilter (I don't know when BTW), but with direction controls to avoid the original issue. Still since the discovery of this issue in 2002, I've been used to check for this support in many firewall products and load balancers I tested, and I've yet to find one which supports this. > Those two NAT routers were connected by a third router that just routed > their between their public addresses. > > Well strictly speaking they were network namespaces created with > ip netns add .. and connected by veth tunnels, but it still worked > and it definitely exercised the proper code paths. > > > And last but not least, it's the only behaviour in TCP which allows a > > random attacker to prevent a connection from establishing by guessing > > only a 16-bit port, regardless of any sequence number. Considering how > > we've been bothered by people who considered that our sequence numbers > > were not random enough, I already expect that the absolute lack of need > > of a sequence number will bring new funny articles. > > I don't quite understand the DOS potential. Is the problem the attacker > makes it look like a different connection has already suceeded so that > legitimate connections get a RST? The memories I have about this were that once the attacker managed to send its SYN to the victim, the socket switched to SYN-RECV with an ack value corresponding to the attacker's seq and definitely refused any valid SYN-ACK from the expected server. > I'm not clear how that differs in practice in DoS potential from simply > spoofing a SYN to a listening port. This is a DoS in that you prevent a client from establishing a connection without having to guess a sequence number. Clients cannot use SYN cookies nor any such mechanism here to protect against such spoofed SYNs. And in practice it's very easy to detect certain port numbers. What I remember from my tests back then is that the product used the default 32768-61000 source port range and made a connection attempt every few minutes (5 or 15 I don't remember). So by sending only a few SYNs per second to the ports you were expecting to be used due to the uptime and the update frequency, you could prevent it from establishing a connection to the remote site. Some variants might also involve having a buddy server on the net receiving one connection form this server to shorten the source port range to attack when the uptime is unknown (eg: web page containing an image, ad, etc). > > Back then, I did a PoC which permanently prevented an anti-virus proxy > > from establishing any connection to its update server, and it did not > > require a lot of traffic obviously. People running such proxies probably > > don't need webrtc with its assorted lot of issues. > > > > I'm not advocating for pushing the patch, I understand it's not desired. > > I just want to ensure that people understand what simultaneous connect > > means in terms of DoS for a feature which is rarely used and rarely > > technically possible at all. > > When the STUNT folks measured the TCP simultaneous open feasiblity back > in 2005 they measured an average 88% success rate in estabilishing TCP > peer connections in the wild. So unless something has changed > drastically (or their mesasurements were wildly inaccurate) it > technically feasible a very interesting percentage of the time. I suspect it works best in environments it targets : end user to end user with almost direct connectivity. > Beyond that it is a sufficiently common trick for establishing peer to > peer communications that an RFC has been written allowing peer to > peer code written by different authors to interoperate. > > I just want to make it clear that for a lot of interesting cases TCP > simultaneous open works today and is very interesting for getting > client machines talking directly to each other. I understand what it can be useful to, I'm just saying that there are environments where this behaviour is clearly not desirable at all, which led me to propose a sysctl so that users could basically decide whether they were in the server camp or in the client camp. Regards, Willy -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index dbca661..2e5bd51 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -431,6 +431,23 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max tcp_sack - BOOLEAN Enable select acknowledgments (SACKS). +tcp_simult_connect - BOOLEAN + Enables TCP simultaneous connect feature conforming to RFC793. + Strict implementation of RFC793 (TCP) requires support for a + feature called "simultaneous connect", which allows two clients to + connect to each other without anyone entering a listening state. + While almost never used, and supported by few OSes, Linux supports + this feature. + + However, it introduces a weakness in the protocol which makes it + very easy for an attacker to prevent a client from connecting to + a known server. The attacker only has to guess the source port + to shut down the client connection during its establishment. The + impact is limited, but it may be used to prevent an antivirus + or IPS from fetching updates and not detecting an attack, or to + prevent an SSL gateway or browser from fetching a CRL. + Default: TRUE + tcp_slow_start_after_idle - BOOLEAN If set, provide RFC2861 behavior and time out the congestion window after an idle period. An idle period is defined at diff --git a/include/net/tcp.h b/include/net/tcp.h index aed42c7..ecd55d0 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -292,6 +292,7 @@ extern int sysctl_tcp_thin_dupack; extern int sysctl_tcp_early_retrans; extern int sysctl_tcp_limit_output_bytes; extern int sysctl_tcp_challenge_ack_limit; +extern int sysctl_tcp_simult_connect; extern atomic_long_t tcp_memory_allocated; extern struct percpu_counter tcp_sockets_allocated; diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c index d84400b..01e475f 100644 --- a/net/ipv4/sysctl_net_ipv4.c +++ b/net/ipv4/sysctl_net_ipv4.c @@ -774,6 +774,15 @@ static struct ctl_table ipv4_table[] = { .extra2 = &two, }, { + .procname = "tcp_simult_connect", + .data = &sysctl_tcp_simult_connect, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec_minmax, + .extra1 = &zero, + .extra2 = &two, + }, + { .procname = "udp_mem", .data = &sysctl_udp_mem, .maxlen = sizeof(sysctl_udp_mem), diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 18f97ca..c71f8bb 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -102,6 +102,7 @@ int sysctl_tcp_thin_dupack __read_mostly; int sysctl_tcp_moderate_rcvbuf __read_mostly = 1; int sysctl_tcp_abc __read_mostly; int sysctl_tcp_early_retrans __read_mostly = 2; +int sysctl_tcp_simult_connect __read_mostly = 1; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ @@ -5846,7 +5847,7 @@ discard: tcp_paws_reject(&tp->rx_opt, 0)) goto discard_and_undo; - if (th->syn) { + if (th->syn && sysctl_tcp_simult_connect) { /* We see SYN without ACK. It is attempt of * simultaneous connect with crossed SYNs. * Particularly, it can be connect to self.
This is based on Willy Tarreau's patch from 2008[1]. The goal is to close a corner-case of TCP that isn't used and poses a small DoS risk. For systems that do not want to take any risk at all, this is a desirable configuration knob. It is possible for two clients to connect with crossed SYNs without checking sequence numbers. As such, it might be possible to guess a source port number to block a system from making connections to well-known ports and IP addresses (e.g. auto-update checks) without requiring a MiTM position. The feature can now be disabled via sysctl: $ echo 0 > /proc/sys/net/ipv4/tcp_simult_connect $ echo ohai | nc -w 1 -p 50000 localhost 50000 -v -v -v nc: connect to localhost port 50000 (tcp) timed out: Operation now in progress nc: connect to localhost port 50000 (tcp) timed out: Operation now in progress $ echo 1 > /proc/sys/net/ipv4/tcp_simult_connect $ echo ohai | nc -w 1 -p 50000 localhost 50000 -v -v -v Connection to localhost 50000 port [tcp/*] succeeded! ohai [1] http://thread.gmane.org/gmane.linux.network/107971 Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Kees Cook <keescook@chromium.org> --- Documentation/networking/ip-sysctl.txt | 17 +++++++++++++++++ include/net/tcp.h | 1 + net/ipv4/sysctl_net_ipv4.c | 9 +++++++++ net/ipv4/tcp_input.c | 3 ++- 4 files changed, 29 insertions(+), 1 deletion(-)