buglwIP - A Lightweight TCP/IP stack - Bugs: bug #66366, LwIP RST not accepted socket close...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #66366: LwIP RST not accepted socket close blocks for several minutes

Submitter:  FoTSav <fotios>
Submitted:  Tue 22 Oct 2024 10:44:29 AM UTC
   
 
Category:  sockets/netconn Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
lwIP version:  2.1.2

Tue 22 Oct 2024 10:44:29 AM UTC, original submission:  

On an embedded system (STM32) running FreeRTOS + LwIP 2.1.2 we use the socket API. We have a desktop application running on Windows or Mac and we can connect to the embedded device using socket to communicate and get status information or send conttrol messages. After connecting and disconnecting to the embedded device several times, so the socket is closed on the desktop side, the embedded device is still sending messages to the closed port. It takes about 18 minutes, till the device closes the socket and can accept a new connection.

We found out, that this only happens when we use a windows PC with firewall on. On Mac or Windows with firewall off, everything works well.

Looking on the wireshark traces when using windows, I see that the seq numbers do not match and the device keeps sending challenge ACK, but with firewall on the PC does not react on them and does not send a RST again.

On the LwIP siede I see that in tcp_in.c in tcp_process

  /* Process incoming RST segments. */
  if (flags & TCP_RST) {
    /* First, determine if the reset is acceptable. */
    if (pcb->state == SYN_SENT) {
      /* "In the SYN-SENT state (a RST received in response to an initial SYN),
          the RST is acceptable if the ACK field acknowledges the SYN." */
      if (ackno == pcb->snd_nxt) {
        acceptable = 1;
      }
    } else {
      /* "In all states except SYN-SENT, all reset (RST) segments are validated
          by checking their SEQ-fields." */
      if (seqno == pcb->rcv_nxt) {
        acceptable = 1;
      } else  if (TCP_SEQ_BETWEEN(seqno, pcb->rcv_nxt,
                                  pcb->rcv_nxt + pcb->rcv_wnd)) {
        /* If the sequence number is inside the window, we send a challenge ACK
           and wait for a re-send with matching sequence number.
           This follows RFC 5961 section 3.2 and addresses CVE-2004-0230
           (RST spoofing attack), which is present in RFC 793 RST handling. */
        tcp_ack_now(pcb);
      }
    }

when firewall is off we get if (seqno == pcb->rcv_nxt) {acceptable = 1}; but with firewall on we get in

else  if (TCP_SEQ_BETWEEN(seqno, pcb->rcv_nxt,
                                  pcb->rcv_nxt + pcb->rcv_wnd))
 tcp_ack_now(pcb);

The thing is on our other devices running linux this problem does not occur. Can anybody help?

Tryed to set acceptable = 1 in the else if TCP_SEQ_BETWEEN(seqno, pcb->rcv_nxt, pcb->rcv_nxt + pcb->rcv_wnd)) does the job but makes the device more vulnerable on a RST spoofing attack.

FoTSav <fotios>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by fotios (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code