received this vuln notice four days before these children intend to
disclose. so you can guess how inclined to embargo.
randy
received this vuln notice four days before these children intend to
disclose. so you can guess how inclined to embargo.
The position doesn't seem to be compatible with e.g.
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
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.
randy
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
"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.
there's a public statement about this from NCSC-NL:
Aanstaande bekendmaking CVD Procedure RPKI | Nieuwsbericht | Nationaal Cyber Security Centrum
"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
there's a public statement about this from NCSC-NL:
Aanstaande bekendmaking CVD Procedure RPKI | Nieuwsbericht | Nationaal Cyber Security Centrum
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
The link doesn't work. 404
https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm
What are the specs of that possible dos vuln?
Is is reflection or amplification or something else?
Thanks
Jean
I looked on english.ncsc.nl’s news section (it’s the most recently published article) and it seems to be referencing OpenBSD’s security page as the reason this “CVD” doesn’t involve the developers and thus isn’t really a CVD.
The link is over linelen characters long and it may have gotten truncated.
* nanog@nanog.org (Jean St-Laurent via NANOG) [Fri 29 Oct 2021, 19:57 CEST]:
The link doesn't work. 404
https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm
X-Mailer: Microsoft Outlook 16.0
The posted link works fine here but your MUA mangled it so you'll have to do some manual work to put the two parts together again. You're missing "aking-cvd-procedure-rpki" at the end.
What are the specs of that possible dos vuln?
¯\_(ツ)_/¯
Is is reflection or amplification or something else?
Maybe you missed the bit where the actual vulnerabilities are under embargo?
-- Niels.
Good news: the disclosure has been postponed
Quoting from:
Update 31 October: Talks have resumed, disclosure is postponed.
Since 30 October, constructive conversation is fortunately taking place
with the parties involved. As such, the NCSC will not publish details
about this vulnerability on Monday 1 November, as previously announced,
but at a later moment (in agreement with the parties involved).
/giovane