FreeBSD Security Advisory: TCP reassembly vulnerability | Hacker News Reader

FreeBSD Security Advisory: TCP reassembly vulnerability

lists.freebsd.org

47 pointsconductor10 comments

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.

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.

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.

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.

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

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'...

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.

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.

I read somewhere that people are calling this TCPBleed.

Is there any evidence that this has already been exploited in the wild?

Reply on news.ycombinator.com