| 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
| ||
|
Message-ID: <AANLkTikbNK-VCPwFcSa5CTyyUoME+xsmxuaQ9EauKs2Z@mail.gmail.com> Date: Tue, 14 Dec 2010 03:35:23 +0300 From: Дмитрий Балакин <dmitriy.balakin@...neiron.ru> To: Eric Dumazet <eric.dumazet@...il.com> Cc: David Miller <davem@...emloft.net>, Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org Subject: Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. 14 декабря 2010 г. 1:31 пользователь Eric Dumazet <eric.dumazet@...il.com> написал: > Le lundi 13 décembre 2010 à 23:44 +0300, Дмитрий Балакин a écrit : >> 2010/12/13 Eric Dumazet <eric.dumazet@...il.com>: >> > Le lundi 13 décembre 2010 à 08:59 -0800, Stephen Hemminger a écrit : >> >> >> >> Begin forwarded message: >> >> >> >> Date: Mon, 13 Dec 2010 14:29:58 GMT >> >> From: bugzilla-daemon@...zilla.kernel.org >> >> To: shemminger@...ux-foundation.org >> >> Subject: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. >> >> >> >> >> >> https://bugzilla.kernel.org/show_bug.cgi?id=24842 >> >> >> >> Summary: Compatibility issue with uggly Windows RFC1323 >> >> implementation. >> >> Product: Networking >> >> Version: 2.5 >> >> Kernel Version: All >> >> Platform: All >> >> OS/Version: Linux >> >> Tree: Mainline >> >> Status: NEW >> >> Severity: normal >> >> Priority: P1 >> >> Component: IPV4 >> >> AssignedTo: shemminger@...ux-foundation.org >> >> ReportedBy: dmitriy.balakin@...neiron.ru >> >> Regression: No >> >> >> >> >> >> Created an attachment (id=40012) >> >> --> (https://bugzilla.kernel.org/attachment.cgi?id=40012) >> >> Patch >> >> >> >> First, sorry for my bad english. >> >> >> >> The issue is that Linux-based OS sometimes can't make an tcp connection to some >> >> Windows servers with switched on buggy implementation of rfc1323, that >> >> described on this forum: >> >> http://www.network-builders.com/windows-tcp-timestamp-not-compliant-rfc-1323-a-t80898.html. >> >> >> >> Because some Windows hosts implementation of rfc1323 bases on randomly >> >> generated TSval and sent first value of TSval as 0, the difference of recent >> >> and new TSval sometimes has been affected by a sign magic issue and the PAWS >> >> mechanism has been triggered. Anyway, the rfc1323 has discribes the condition >> >> of PAWS as "0 < (t - s) < 2**31", that has been right implementation in current >> >> linux kernel, but incompatible with Windows bug. >> >> >> >> For example, the one of affected to this issue Windows host is behind >> >> relay.n-l-e.ru:80 >> >> >> >> I think that my small patch makes the kernel more compatible with this windows >> >> bug. >> >> >> >> - >> > >> > I have no problem connecting my linux client to relay.n-l-e.ru:80 >> > >> > Could you elaborate please ? >> > >> > 18:13:12.444250 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [S], >> > seq 665972386, win 5840, options [mss 1460,sackOK,TS val 1746885 ecr >> > 0,nop,wscale 7], length 0 >> > 18:13:12.473912 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [S.], >> > seq 190215045, ack 665972387, win 5792, options [mss 1460,sackOK,TS val >> > 730697107 ecr 1746885,nop,wscale 0], length 0 >> > 18:13:12.473976 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.], >> > ack 1, win 46, options [nop,nop,TS val 1746888 ecr 730697107], length 0 >> > 18:13:14.984153 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.], >> > seq 1:8, ack 1, win 46, options [nop,nop,TS val 1747139 ecr 730697107], >> > length 7 >> > 18:13:15.013901 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.], >> > ack 8, win 5792, options [nop,nop,TS val 730697360 ecr 1747139], length >> > 0 >> > 18:13:15.377879 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.], >> > seq 8:10, ack 1, win 46, options [nop,nop,TS val 1747178 ecr 730697360], >> > length 2 >> > 18:13:15.403900 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.], >> > ack 10, win 5792, options [nop,nop,TS val 730697399 ecr 1747178], length >> > 0 >> > 18:13:15.461384 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [P.], >> > seq 1:159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr >> > 1747178], length 158 >> > 18:13:15.461429 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.], >> > ack 159, win 54, options [nop,nop,TS val 1747186 ecr 730697405], length >> > 0 >> > 18:13:15.461448 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [F.], >> > seq 159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr >> > 1747178], length 0 >> > 18:13:15.461607 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [F.], >> > seq 10, ack 160, win 54, options [nop,nop,TS val 1747186 ecr 730697405], >> > length 0 >> > 18:13:15.533846 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.], >> > ack 11, win 5792, options [nop,nop,TS val 730697412 ecr 1747186], length >> > 0 >> > >> > >> > >> >> Problems occur only when the remote side sets the TC val > 2147483647, >> ie when there is a sign: >> > > You mean a windows machine with a big uptime ? > That must be quite rare indeed ;) > > Anyway, we can not test values like suggested patch, or risk a problem > when wrap around occurs... > > However, testing the special ts_recent=0 case would be possible (we > already did a change to accept a windows initiated connect to a linux > server and still activate tcp timestamps) > > (commit fc1ad92dfc4e363a055 tcp: allow timestamps even if SYN packet has > tsval=0) > > Something like following patch ? > > Thanks > > > [PATCH net-next-2.6] tcp: relax tcp_paws_check() > > Some windows versions have wrong RFC1323 implementations, with SYN and > SYNACKS messages containing zero tcp timestamps. > > We relaxed in commit fc1ad92dfc4e363 the passive connection case > (Windows connects to a linux machine), but the reverse case (linux > connects to a Windows machine) has an analogue problem when tsvals from > windows machine are 'negative' (high order bit set) : PAWS triggers and > we drops incoming messages. > > Fix this by making zero ts_recent value special, allowing frame to be > processed. > > Based on a report and initial patch from Dmitiy Balakin > > Bugzilla reference : https://bugzilla.kernel.org/show_bug.cgi?id=24842 > > Reported-by: dmitriy.balakin@...neiron.ru > Signed-off-by: Eric Dumazet <eric.dumazet@...il.com> > --- > include/net/tcp.h | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 3f227ba..2ab6c9c 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -1038,7 +1038,13 @@ static inline int tcp_paws_check(const struct tcp_options_received *rx_opt, > return 1; > if (unlikely(get_seconds() >= rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS)) > return 1; > - > + /* > + * Some OSes send SYN and SYNACK messages with tsval=0 tsecr=0, > + * then following tcp messages have valid values. Ignore 0 value, > + * or else 'negative' tsval might forbid us to accept their packets. > + */ > + if (!rx_opt->ts_recent) > + return 1; > return 0; > } > > > > In Windows uptime should be about 7 years old to sign is appear in a TS value, it really should be quite rare. But there is such a systems, where the TS value has nothing to do with uptime and randomly generated for each TCP connection, such as the one referred to earlier. Yes, you're right, my patch breaks the PAWS. Your patch is the right way. 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
Powered by blists - more mailing lists