

FreeBSD Security Advisory: TCP reassembly vulnerability - conductor
http://lists.freebsd.org/pipermail/freebsd-announce/2014-April/001546.html

======
tptacek
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
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
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
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.

------
tlb
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

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

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

