Subject: [Sidrops] possible rsync validation dos vuln

From: Randy Bush <[email-masked]>
Date: Thu, 28 Oct 2021 18:03:58 -0700

received this vuln notice four days before these children intend to
disclose.  so you can guess how inclined to embargo.

randy

From: Koen van Hove <[email-masked]>
Subject: CVD: Vulnerabilities in RPKI Validators
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Wed, 27 Oct 2021 14:59:21 -0700

Dear Randy Bush and Rob Austein,

Apologies, this email was previously sent to the wrong email address.

On behalf of the University of Twente and the National Cyber Security
Centre of the Netherlands (NCSC-NL) we want to notify you of a Coordinated
Vulnerability Disclosure for RPKI vulnerabilities that also impact rcynic
developed by Dragon Research Labs.

The vulnerabilities were discovered by scientific research on the
implementation of RPKI validators.
Together with you, the NCSC-NL, the University of Twente, and multiple
other parties, we would like to come to a timely solution before the
results of this research will be made public. More information about
Coordinated Vulnerability Disclosure can be found here [1].

The vulnerabilities are classified as a denial of service vulnerability and
impact multiple implementations of RPKI validators including rcynic. Since
RPKI is of international interest we hope that you will work together with
us on this CVD.

The goal is to have fixes available before 1 November which will also be
the date that the results of this research will become public. Before 1
November the information in the CVD, or the fact that a CVD is taking
place, is to be kept strictly confidential. The fixes are to be released
collectively on 1 November.

Please let us know whether you agree to these terms, and want to
participate in this CVD. If so, we will send you the details. We hope to
hear from you.

If there are any further questions, please let us know.

Yours sincerely,

Koen van Hove
University of Twente

[1] https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd

- --
Koen van Hove

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 29 Oct 2021 10:26:53 +0100

> disclose.  so you can guess how inclined to embargo.

The position doesn't seem to be compatible with e.g.

> https://www.first.org/global/sigs/vulnerability-coordination/multiparty/FIRST-Multiparty-Vulnerability-Coordination.pdf

At the top of the FIRST list:

> 1. Establish a strong foundation of processes and relationships
> 
> 2. Maintain clear and consistent communications
> 2.1. All parties should clearly and securely communicate and negotiate expectations and timelines.

Because this didn't happen, we now get to look forward to a weekend of 
elevated risk, followed by people upending their calendars to handle 
un-coordinated upgrades on monday morning.

Vulnerability researchers perform a valuable service, but enthusiasm 
needs to be tempered with an understanding that there are real life 
consequences to not handling this sort of thing in a well-structured 
way.  It doesn't need to be said that: "1. we screwed up with your email 
address, and 2. we're disclosing in 4 days and aren't telling you what 
the problem is unless you agree to our terms" is not an appropriate way 
of handling anything, whatever about claiming to speak on behalf of an NCSC.

This won't be the last time a screw-up of this form happens, so maybe 
NCSC-NL's takeaway should be to ensure that co-ordinated vuln management 
and disclosure happens in a reasonable way when engaging with all parties?

As a separate thing, software authors also need to have clearly defined 
security notification points and vulnerability management policies. 
Most have in this situation, but not all.

Nick

> -----BEGIN PGP SIGNATURE-----
> Version: FlowCrypt Email Encryption 8.1.5
> Comment: Seamlessly send and receive encrypted email
> 
> wsDzBAEBCgAGBQJhecu4ACEJEPnqm/++VTh9FiEE5Q3GCKqW0RQyUpA/+eqb
> /75VOH1CjwwAq8Hd0psDhfj6mL4X9ybLGogONpzFKYp9Okv9/CKzQvG4AkLR
> Cvrz3vHlQRKJP8I2PYSLZvtG9D/HXjjKcU+m24jjl2qbKKuSwprqQhLAqabN
> Md+RZFjQGve5Z4vtJsfhXKc4PhaAzMujVc4Mh5Mdbs4sFEdrub1hSnYKlcQV
> PvS/O9SpCYU0E0IC1I455HXxSXUtme+KHtzbGIWQe/mz4KpnZD2Me/Cr1LvG
> Od9izri0Qx5vF+kdpR51PEiwHgN+QkmnUP6Gkrca8TSC2x3ta9B1/ZprdCoZ
> ZYQ7QUFUAkfV+tKCMaBECNOrnDjw8E9GonvzmqpDHBtKBZ3LaxjZX/sxuuTC
> +Ele5nVeWW0ZFqrbanbPy9y1q04tFQd8ewdSN40iXdTj7Ha8GadUhcdSLWqJ
> cLmf71qUAvdwpp0Bt1nhExpU/bEtAaxfnEcTRDX43yUkZXSqV5BxYEyneSLj
> IvFV9AUi56Cx45ESkGRR1ASuCzoc8FCjRH7KOWnaL3fl
> =YQZI
> -----END PGP SIGNATURE-----
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Oct 2021 05:01:59 -0700

i would not be surprised if email to my previous addresses

   ...!uunet!m2xenix!randy
   ...!uunet!oresoft!randy

bounced, making it difficult for these kiddies to reach me.

https://en.wikipedia.org/wiki/Responsible_disclosure

randy

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 29 Oct 2021 13:36:54 +0100

Barry Greene wrote on 29/10/2021 13:15:
> That only happens if the team has the time to get the fix into the code, 
> tested, validated, regressed, and deployed. I would say this is a 
> classic example of “ego” to publish overruling established principles.
> 
> The University of Twente should explore requiring classes for 
> responsible disclosure.
> 
> NCSC, it seems you threw out your own policy:
> 
> "The NCSC will try to resolve the security problem that you have 
> reported in a system within 60 days. Once the problem has been resolved, 
> we will decide in consultation whether and how details will be published.”
> 
> I would have expected you to council the researchers on responsible 
> disclosure principles.

Indeed + also manage the vendor disclosure process in a more 
comprehensive / structured way.

An interesting and worthwhile outcome here would be a presentation on 
how the set of inputs into the sausage factory produced the mess that's 
going to be served for lunch on monday.  I.e. let's use this as an 
opportunity to learn from the mistakes that were made here.

Nick

---

From: Barry Greene <[email-masked]>
Date: Fri, 29 Oct 2021 20:15:43 +0800

> On Oct 29, 2021, at 5:26 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Because this didn't happen, we now get to look forward to a weekend of elevated risk, followed by people upending their calendars to handle un-coordinated upgrades on monday morning.

That only happens if the team has the time to get the fix into the code, tested, validated, regressed, and deployed. I would say this is a classic example of “ego” to publish overruling established principles.

The University of Twente should explore requiring classes for responsible disclosure.

"The NCSC will try to resolve the security problem that you have reported in a system within 60 days. Once the problem has been resolved, we will decide in consultation whether and how details will be published.”

I would have expected you to council the researchers on responsible disclosure principles.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 29 Oct 2021 17:28:27 +0100

there's a public statement about this from NCSC-NL:

> https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki

"In dit proces is een afweging gemaakt om de ontwikkelaar van 
RPKI-client pas later te informeren. Deze afweging is gemaakt op basis 
van het publieke standpunt van deze ontwikkelaars, namelijk steun voor 
‘full disclosure’. De ontwikkelaars van RPKI-client hebben het NCSC 
laten weten dat zij niet akkoord gaan met betrokkenheid onder embargo."

"During this process, a decision was made to inform the developer of 
RPKI-client at a later stage.  This decision was made on the basis of 
the public standpoint of these developers, namely support for 'full 
disclosure.  The developers of RPKI-client have let the NCSC know that 
they do not agree with involvement under embargo."

Looks like the NCSC got confused about OpenBSD's internal security vuln 
management  process, which involves full disclosure on their terms, and 
the way they operate with disclosures from third parties / multiparty 
engagement, which involves co-operation with the disclosing party / CERT 
about mutually acceptable terms, including co-ordinated disclosure, i.e. 
standard industry practice.  Some public clarity from the openbsd people 
would help here.

+ there was a screwup with the rcynic developers.

It's a bit much to claim that the openbsd (+ rcynic) people didn't agree 
with involvement under embargo when the terms were apparently: we're 
releasing details in 4 days and will only tell you what the problem is 
if you agree to this.

Regardless of how this misunderstanding came about, this style of 
approach doesn't form part of an acceptable vulnerability management 
process.

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Oct 2021 10:10:26 -0700

>> https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki

blah blah blah

bottom line.  they gave first notice to devs 4 days before threatened
disclosure.  that they then asked to embargo was just adding insult to
injury.

we will remember their names.  like the herzberg incident, "the internet
has two weeks to upgrade all microtiks globally before we intentionally
break it again."

would they do the same to the electric grid or other scada network?  the
internet's openness and kindness has led them to think we can be abused
willy nilly.

we will remember their names.

randy