lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #50837] LWIP TCP/IP race condition


From: Joel Cunningham
Subject: [lwip-devel] [bug #50837] LWIP TCP/IP race condition
Date: Mon, 1 May 2017 23:05:19 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0

Follow-up Comment #16, bug #50837 (project lwip):

preet,

Thanks for the update.  I analyzed the wireshark logs and have a couple of
findings to report:

1) LwIP 2.0.2 is now sending zero window probes from server to client, but
unfortunately this does not re-trigger an RST after the challenge ACK from the
windows client.

I'm not sure why Windows does not respond to the challenge ACK.  I found some
evidence online that Windows has yet to implement RFC 5961, which may or may
not explain it's ACK processing once the control block has been reset

If anyone remembers back in August of 2016, the Linux kernel came into the
news with an exploit that took advantage of the implementation of RFC 5961. 
See here:
https://arstechnica.com/security/2016/08/linux-bug-leaves-usa-today-other-top-sites-vulnerable-to-serious-hijacking-attacks/.
 This article and the underlying security paper both claim Windows has not
implemented RFC 5961

See section 8 here:
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf

2) The thing that still didn't seem right to me (which I mentioned in comment
#11) is that if a TCP socket is sending, a dead connection should eventually
timeout.  Now with LwIP 2.0.2, we've got the zero window probes fixed and
working, but the connection still lingers indefinitely.

Taking a look at the persist timer implementation in tcp_slowtmr(), once we
hit the largest exponential backoff, we don't close the connection, but
instead just repeat the probing at the largest value.  The connection is only
closed if pcb->nrtx >= TCP_MAXRTX and pcb->nrtx is not incremented for the
persist timer logic.

I reviewed the zero window probe specification from RFC 1122 (section
4.2.2.17):


A TCP MAY keep its offered receive window closed
indefinitely.  As long as the receiving TCP continues to
send acknowledgments in response to the probe segments, the
sending TCP MUST allow the connection to stay open.


https://tools.ietf.org/html/rfc1122#section-4.2.2.17

In the case provided by preet, the remote TCP is not responding to the probes
and nothing is sent after the RST.  You can see at the end of the capture,
there are 6 probes that are 60 seconds apart, which is the last tier in
tcp_persist_backoff[].  I'm guessing preet stopped the capture at this point.

Regardless of the RST that was not processed, we should time out.  This case
is really no different then if the wire was silently disconnected during the
zero-window condition

Section 4.2.2.17 goes on to mention that the zero-window probe logic should
backoff like the regular RTO and the two mechanisms may even be combined into
the same implementation.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?50837>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]