[Bug 274550] Reporting side channels in TCP/UDP/ICMP implementation

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274550

            Bug ID: 274550
           Summary: Reporting side channels in TCP/UDP/ICMP implementation
           Product: Base System
           Version: 13.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: fqy5067@psu.edu

We are writing to report several potential side-channel vulnerabilities in
FreeBSD kernel version 13.2. Each potential vulnerability is identified by a
static code analysis tool that we have developed to detect potential side
channels in TCP and UDP protocols. In the settings, we have marked port number
(TCP, UDP), sequence number (TCP) and acknowledge number (TCP) as sensitive
information. 

Each identified branch below might leak sensitive information (as in the
settings mentioned above) to an off-path attacker. **While the reported
branches have information leakage from the prospective of static analysis, it
is still unsure whether it is possible to construct an attack.** For each
branch in the program, we provide what information is leaked (WHAT) and how an
attacker can reveal the information (HOW), and a description of a potential
packet that could trigger the branch condition (INPUT):


1. (patched) /sys/netinet/udp_usrreq.c: L614, in udp_input()
    INPUT: UDP pkt with guessed port number
    WHAT:  whether the guessed port number is correct
    HOW: ICMP pkt vs NULL
2. /sys/netinet/tcp_input.c: L3299, in tcp_do_segment()
    INPUT: ACK pkt to a connection in LAST-ACK
    WHAT: whether the guessed sequence number is in-window
    HOW: TCP pkt vs NULL
3. /sys/netinet/tcp_input.c: L2583, in tcp_do_segment()
    INPUT: ACK pkt to a connection in LAST-ACK
    WHAT: whether the guessed acknowledge number is in-window
    HOW: TCP pkt vs NULL
4. /sys/netinet/tcp_input.c: L1937, in tcp_do_segment()
    INPUT: ATK pkt to an ESTABLISHED connection
    WHAT: whether the guessed sequence number is in-window
    HOW: Immediate ACK vs Delayed ACK
5. /sys/netinet/tcp_input.c: L1870, in tcp_do_segment()
    INPUT: ATK pkt to an ESTABLISHED connection
    WHAT: whether the guessed acknowledge number is in-window
    HOW: TCP pkt vs NULL
6. /sys/netinet/tcp_input.c: L2470, in tcp_do_segment()
    INPUT: ACK pkt to a connection in LAST-ACK when V_tcp_do_rfc3042 is enabled
    WHAT: whether the guessed acknowledge number is in-window
    HOW: TCP pkt vs NULL
7. /sys/netinet/tcp_input.c: L3328, in tcp_do_segment()
    INPUT: ACK pkt to a connection in SYN-RCVD
    WHAT: whether the guessed port has an active connection
    HOW: TCP RST pkt vs NULL
8. /sys/netinet/ip_icmp.c: L1149, in badport_bandlim()
    INPUT: pkt that triggers any of the limits (TCP bad port, UDP bad port,
etc.)
    WHAT: whether the guessed port has an active connection
    HOW: triggered response (TCP/ICMP) pkt vs NULL
9. /sys/netinet/tcp_input.c: L2161, in tcp_do_segment()
    INPUT: RST pkt to a non LISTEN/SYN-SENT connection
    WHAT: whether the guessed sequence number is smaller than expected
    HOW: Challenge ACK vs NULL
10. /sys/netinet/tcp_input.c: L2795, in tcp_do_segment()
    INPUT: ACK pkt to an ESTABLISHED connection
    WHAT: whether the guessed acknowledge number is in-window
    HOW: TCP pkt vs NULL

(1)(8) may result in leakage of UDP connection identifiers. (2)-(10) may result
in leakage of TCP connection identifiers. 


We are reporting these findings for ethical reasons, and would like to hear
your opinion on the above vulnerabilities, if any. Please let us know if you
need more information.

-- 
You are receiving this mail because:
You are the assignee for the bug.