netdev - Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.

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

Date:	Mon, 13 Dec 2010 08:59:13 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	netdev@...r.kernel.org
Subject: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323
 implementation.

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.

-- 
--- include/net/tcp.h.orig	2010-12-02 04:41:22.000000000 +0300
+++ include/net/tcp.h	2010-12-13 13:58:05.000000000 +0300
@@ -1077,9 +1077,10 @@
 }

 static inline int tcp_paws_check(const struct tcp_options_received *rx_opt,
-				 int paws_win)
+				unsigned int paws_win)
 {
-	if ((s32)(rx_opt->ts_recent - rx_opt->rcv_tsval) <= paws_win)
+	if (rx_opt->ts_recent < rx_opt->rcv_tsval ||
+			rx_opt->ts_recent - rx_opt->rcv_tsval <= paws_win)
 		return 1;
 	if (unlikely(get_seconds() >= rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS))
 		return 1;

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