tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

To test presence of CVE-2018-6922 ( TCP vulnerability) in NetBSD5.1



I am trying to test presence of  CVE-2018-6922 ( TCP vulnerability) in NetBSD5.1
As I understand this version is not anymore supported and we are in process of upgrading.
However, it may take sometime before I could achieve that and hence meanwhile for existing setup I need this information.

When I looked into fix provided by FreeBSD, it is talking of adding an upper limit to the reassembly queue but when I referred back I don't see any similar threshold in older code.

https://www.freebsd.org/security/advisories/FreeBSD-SA-18:08.tcp.asc

Therefore, I am assuming that, our older code is vulnerable to DoS attack as described in CVE.

I have few questions on this :

1. Does this community thinks that NetBSD5.1 is vulnerable to the said CVE?
2. Are there any specific conditions under which the issue can be reproduced easily? For Example, if using SACK option may increase the chance.
3. Is it safe or a good idea to backport the fix from NetBSD 8 (when available) to NetBSD 5.1?
4. Wanted to confirm if the code excerpt below ( tcp_input() ) is most probable to call tcp_reass() to trigger the DoS scenario.

   1 /*      $NetBSD: tcp_input.c,v 1.291.4.5 2010/06/11 23:36:07 riz Exp $  */
   2
   3 /*
   4  * Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
   5  * All rights reserved.


         if ((tlen || (tiflags & TH_FIN)) &&
             TCPS_HAVERCVDFIN(tp->t_state) == 0) {
                 /*
                  * Insert segment ti into reassembly queue of tcp with
                  * control block tp.  Return TH_FIN if reassembly now includes
                  * a segment with FIN.  The macro form does the common case
                  * inline (segment is the next to be received on an
                  * established connection, and the queue is empty),
                  * avoiding linkage into and removal from the queue and
                  * repetition of various conversions.
                  * Set DELACK for segments received in order, but ack
                  * immediately when segments are out of order
                  * (so fast retransmit can work).
                  */
                 /* NOTE: this was TCP_REASS() macro, but used only once */
                 TCP_REASS_LOCK(tp);
                 if (th->th_seq == tp->rcv_nxt &&
                     TAILQ_FIRST(&tp->segq) == NULL &&
                     tp->t_state == TCPS_ESTABLISHED) {
                         tcp_setup_ack(tp, th);
                         tp->rcv_nxt += tlen;
                         tiflags = th->th_flags & TH_FIN;

                         tcps = TCP_STAT_GETREF();
                         tcps[TCP_STAT_RCVPACK]++;
                         tcps[TCP_STAT_RCVBYTE] += tlen;
                         TCP_STAT_PUTREF();
                         nd6_hint(tp);
                         if (so->so_state & SS_CANTRCVMORE)
                                 m_freem(m);
                         else {
                                 m_adj(m, hdroptlen);
                                 sbappendstream(&(so)->so_rcv, m);
                         }
                         TCP_REASS_UNLOCK(tp);
                         sorwakeup(so);
                 } else {
                         m_adj(m, hdroptlen);
                         tiflags = tcp_reass(tp, th, m, &tlen);
                         tp->t_flags |= TF_ACKNOW;
                         TCP_REASS_UNLOCK(tp);
                 }

I am not a protocol expert, but I see that this code belongs to the case after connection got established and FIN was not received.

Need Help

--
Regards
Ripunjay Tripathi



Home | Main Index | Thread Index | Old Index