Vulnurability Disclosure - How does it happen?

505 views
Skip to first unread message

Amir Omidi (aaomidi)

unread,
May 23, 2024, 11:54:43 AMMay 23
to dev-secur...@mozilla.org
Hey folks,


(I've marked my questions in bold)

I'm mainly basing this discussion around: https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to understand what the intent of some of the wording in this is, and how it applies to CAs.

In that wiki, we see:

> Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP.

What is Mozilla's intent by the phrase "must be reported if they pose ongoing risk to the overall integrity and security of CA operations."

More specifically:
  1. "Disclosed" to whom? Public? Just Mozilla?
  2. What does "if they pose an ongoing risk" mean? If its a one-off attack, does that mean it does not need to be disclosed?
I'm also unsure about trusting CAs to determine the significance of such an attack. We've seen recently that a few CAs have really jumped to making claims such as "this incident has no security impact" before doing any proper RCA or even understanding the extent of the incident. Has Mozilla found any issues with leaving the determination up to CAs in the past?

More broadly, how does this wiki work when read in conjunction with the Mozilla Root Store Policy

Specifically, section 2.4:

> When a CA operator fails to comply with any requirement of this policy - whether it be a misissuance, a procedural or operational issue, or any other variety of non-compliance - the event is classified as an incident and MUST be reported to Mozilla as soon as the CA operator is made aware.

Is a security incident like the one I posted above considered an instance of a CA "failing to comply"?

In 2.4.1 we see:

> Additionally, and not in lieu of the requirement to publicly report incidents as outlined above, a CA Operator MUST disclose a serious vulnerability or security incident in Bugzilla as a secure bug in accordance with guidance found on the Vulnerability Disclosure wiki page.

From my reading here, this means that all security vulnerabilities are being disclosed privately to Mozilla. I guess this kind of makes sense here.

Would Mozilla be open to having a limited cooling-off period where these secure bugs stay private, but after that period the information becomes public?

My justification for asking this is:
  • Other CAs can and should learn from how a CA responded to a security incident.
  • There may be commonalities in attack patterns that these incidents being public can help surface.
  • It reassures the community that these incidents are being taken seriously by allowing third parties to also verify and validate the incident response and mitigation items.

Beyond this, I'd also be interested in hearing if Chunghwa Telecom has disclosed the impact of this recent attack on their systems (if any) to Mozilla and the other root programs.


Mike Shaver

unread,
May 23, 2024, 12:56:40 PMMay 23
to Amir Omidi (aaomidi), dev-secur...@mozilla.org
Historically at least, Mozilla secure bugs are kept closed only while publishing the information would itself be harmful to the security of Mozilla’s users or others on the web. Relevant patches are out, etc. We held fuzzing tools back for a year or so because another major browser had a hard time getting all the exposed bugs sorted out, at the limit.

I’m not sure how to map that into the CA-breach case, tbh. There usually isn’t *public* harm that results from the world knowing that someone has been breached. Or maybe there is, and I’m just not thinking of it?

Mike

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b9fa92df-2d48-4740-988c-a147285e181dn%40mozilla.org.

Ben Wilson

unread,
May 23, 2024, 1:07:39 PMMay 23
to Amir Omidi (aaomidi), dev-secur...@mozilla.org
Amir,
To answer the last question first, Chunghwa Telecom did not disclose this recent attack, but I don't think we have sufficient information from the article to determine the effects of the breach on the CA operations. So without more information, it might be premature to answer the question, "Is a security incident like the one I posted above considered an instance of a CA "failing to comply"?" 
The process envisioned by the policy and guidance does contemplate that these disclosures would be in a secure bug (to which Mozilla would grant other root programs access). It also contemplates that another, public bug would need to be created, using the incident-reporting template (including a description of the CA's incident response). Finally, because this is a new process, we do not yet have any experiences to share or to use in evaluating the success or shortcomings of the requirement.
Ben

Amir Omidi (aaomidi)

unread,
May 23, 2024, 1:59:33 PMMay 23
to dev-secur...@mozilla.org, Ben Wilson, dev-secur...@mozilla.org, Amir Omidi (aaomidi)
Thanks. I guess this question then is aimed at Chunghwa Telecom to let us know if what's been reported has had any impact on their CA systems.

Aaron Gable

unread,
May 23, 2024, 2:08:15 PMMay 23
to Amir Omidi (aaomidi), dev-secur...@mozilla.org, Ben Wilson
Although it was not the result of a security breach or other directed attack, I can provide this bugzilla bug as an example of what an embargoed incident report followed by public disclosure has looked like in the past.

Aaron

Li-Chun CHEN

unread,
May 25, 2024, 6:25:09 AMMay 25
to dev-secur...@mozilla.org, Amir Omidi (aaomidi), Ben Wilson, dev-secur...@mozilla.org
Our company's CA system is independent of telecommunications system. There is no impact on Chunghwa Telecom's CA System related to that data breach news. Chunghwa Telecom will continue to strengthen the system & network security control of the CA system to ensure data security. Thank you.

   Li-Chun Chen
   Chunghwa Telecom
   

Amir Omidi (aaomidi) 在 2024年5月24日 星期五凌晨1:59:33 [UTC+8] 的信中寫道:

Wayne

unread,
May 30, 2024, 10:31:04 AMMay 30
to dev-secur...@mozilla.org, dev-secur...@mozilla.org
To bring this discussion back up what is the required impact for disclosure? To move the discussion away from Chunghwa Telecom, there also was Lockbit ransomware deployed at Entrust in June '22 and at least 400GB+ data exfiltrated. We have not had a public report of what data relevant to CA operations was obtained. Although correct me if I am wrong I've not delved that deeply into the subject.

Keeping to the technical level and leaving the minefield of personal information to the side for this discussion...

What aspects of the CA operation must be impacted for this to be a notifiable event? Presumably anything directly impacting the HSMs, certificate's private keys, or issuance. How many steps removed from that process is fine?

Moving to indirect security aspects, would this also apply to pentest reports on the CA infrastructure? I'd presume there's also a lot of information generated in Webtrust or ETSI audits that would also be material to the security environment.

Given this is a recent real world scenario I think it would be a good example to work through.
Reply all
Reply to author
Forward
0 new messages