6 ms·

FreeBSD Security Advisory: TCP reassembly vulnerability

• chippy1337 12y ago
  Packet reassembly, causing crashes since the days of WinNuke.
• XERQ 12y ago
  Is there any evidence that this has already been exploited in the wild?
• tlb 12y ago
  The patch shows the nature of the error: Index: sys/netinet/tcp_reass.c =================================================================== --- sys/netinet/tcp_reass.c (revision 264836) +++ sys/netinet/tcp_reass.c (working copy) @@ -211,7 +211,7 @@ tcp_reass(struct tcpcb *tp, struct tcphdr *th, int * Investigate why and re-evaluate the below limit after the behaviour * is understood. */ - if (th->th_seq != tp->rcv_nxt && + if ((th->th_seq != tp->rcv_nxt || !TCPS_HAVEESTABLISHED(tp->t_state)) && tp->t_segqlen >= (so->so_rcv.sb_hiwat / tp->t_maxseg) + 1) { V_tcp_reass_overflows++; TCPSTAT_INC(tcps_rcvmemdrop); @@ -234,7 +234,7 @@ tcp_reass(struct tcpcb *tp, struct tcphdr *th, int */ te = uma_zalloc(V_tcp_reass_zone, M_NOWAIT); if (te == NULL) { - if (th->th_seq != tp->rcv_nxt) { + if (th->th_seq != tp->rcv_nxt || !TCPS_HAVEESTABLISHED(tp->t_state)) { TCPSTAT_INC(tcps_rcvmemdrop); m_freem(m); *tlenp = 0; @@ -282,7 +282,8 @@ tcp_reass(struct tcpcb *tp, struct tcphdr *th, int TCPSTAT_INC(tcps_rcvduppack); TCPSTAT_ADD(tcps_rcvdupbyte, *tlenp); m_freem(m); - uma_zfree(V_tcp_reass_zone, te); + if (te != &tqs) + uma_zfree(V_tcp_reass_zone, te); tp->t_segqlen--; /* * Try to present any queued data
• tptacek 12y ago
  This advisory is written to create the impression that the impact of the vulnerability is limited. But this is a memory corruption flaw. I've heard rumors that there are bigger problems here than simply crashing hosts or leaking memory, but it's possible that the code execution scenarios people are talking about rely on some second bug, coupled with kernel information leaks. Either way, patch this quickly.
  • cperciva 12y ago
    I'd like to hear any details of the rumours you're talking about. We looked carefully at this bug and couldn't find any potential for more severe impacts -- even the kernel memory leakage is hard for remote attackers, since the memory is leaked to the local side of the connection, not the remote side.
    • zaroth 12y ago
      It's probably not too hard to get a web server to effectively echo the 'corrupt' / reassembled packet it eventually receives? I guess it depends on how much control you have over the content that directly precedes the disclosed kernel memory. But there are probably ways to get a system to echo the data it receives that are less likely to be logged.
      • cperciva 12y ago
        Web servers are why we decided that extracting data would be possible in some circumstances; the problems of needing to get the stack fragment to appear in the right place following the right data was why I said it would be difficult.
• zaroth 12y ago
  Almost sounds like Heartbleed in the TCP stack... Additionally, because the undefined on stack memory may be overwritten by other kernel threads, while extremely difficult, it may be possible for an attacker to construct a carefully crafted attack to obtain portion of kernel memory via a connected socket. This may result in the disclosure of sensitive information such as login credentials, etc. before or even without crashing the system. I'm sure there's some great branding opportunities around 'tcp_reass.c'...
  • tptacek 12y ago
    Heartbleed-style vulnerabilities aren't rare. At a security conference several years ago, someone dumped a full image of a running core router with one of them.
  • cperciva 12y ago
    No, it has far more in common with the other recent OpenSSL bug -- use-after-free resulting in data potentially getting spliced into the wrong connection.
  • eyeareque 12y ago
    I read somewhere that people are calling this TCPBleed.