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]
Message-ID: <20101213085913.374c1072@nehalam>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ