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

[Alistair Crooks]

On Fri, 10 Aug 2018 at 08:01, Ripunjay Tripathi 
wrote:

> Thanks for the link.
>
> On Fri, Aug 10, 2018 at 3:19 PM Maxime Villard  wrote:
>
>> Le 10/08/2018 à 11:18, Ripunjay Tripathi a écrit :
>> > I am trying to test presence of CVE-2018-6922 [...]
>>
>> NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach EOL. So
>> there is no way this is ever going to be fixed in NetBSD 5.
>>
>> I know that. I am interested in understanding if someone has already
> tested the presence OR could help me in my attempts to reproduce this.
> I also need to fix this therefore wanted to be sure if my understanding of
> code tcp_input() is correct.
>

I think you are mistaken - there is no need to fix - see yesterday's
conversation on tech-net, as maxv mentioned, and this from 14 years ago:

https://mail-index.netbsd.org/netbsd-announce/2004/03/04/.html

I know the code in question is opaque, but its effects should be obvious
when running the exploit code.

Regards,
Alistair

PS. CERT-CC were informed that NetBSD was not affected in advance of
publication, but haven't updated their list of vendors to include that.

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

[Ripunjay Tripathi]

Thanks for the link.

On Fri, Aug 10, 2018 at 3:19 PM Maxime Villard  wrote:

> Le 10/08/2018 à 11:18, Ripunjay Tripathi a écrit :
> > I am trying to test presence of CVE-2018-6922 [...]
>
> NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach EOL. So
> there is no way this is ever going to be fixed in NetBSD 5.
>
> I know that. I am interested in understanding if someone has already
tested the presence OR could help me in my attempts to reproduce this.
I also need to fix this therefore wanted to be sure if my understanding of
code tcp_input() is correct.

> There was a small conversation about the issue yesterday, in case you're
> interested:
>
> http://mail-index.netbsd.org/tech-net/2018/08/09/msg007004.html
>
> Maxime
>

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

[Mouse]

>> I am trying to test presence of CVE-2018-6922 [...]
> NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach
> EOL.  So there is no way this is ever going to be fixed in NetBSD 5.

That's a bit of an overstatement.  Not fixed _by NetBSD_, perhaps, but
there are at least a few people still using and, to some extent,
maintaining EOLed NetBSD.  I, for example, still run and evolve 5.2,
among others.

> There was a small conversation about the issue yesterday, in case
> you're interested: [...]

But NetBSD is vulnerable if the threat model includes malicious
attacks, even if it is resistant against pathological behaviour
provoked by random fragment loss.  (For that matter, it's not clear
from the reply whether the statement applies to all NetBSD or only
recent NetBSD - though code inspection makes it appear it's true of
1.4T and 5.2 and presumably everything in between.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

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

[Maxime Villard]

Le 10/08/2018 à 11:18, Ripunjay Tripathi a écrit :

I am trying to test presence of CVE-2018-6922 [...]


NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach EOL. So
there is no way this is ever going to be fixed in NetBSD 5.

There was a small conversation about the issue yesterday, in case you're
interested:

http://mail-index.netbsd.org/tech-net/2018/08/09/msg007004.html

Maxime

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

[Ripunjay Tripathi]

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
$  */   23 /*   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