499178 - Clarification requested regarding remediation of StartCom certificate issuance vulnerability

Status: RESOLVED WORKSFORME

(CA Program :: CA Certificate Root Program, task)

Description

[Sam Johnston]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1) Gecko/20090615 Firefox/3.5
Build Identifier: 

StartCom was recently found to have had a vulnerability in it's Ajax based certificate issuance system whereby users could request a certificate for any domain.

Detailed clarification is requested as to how this issue was remediated. Specifically, how was it possible to verify that all issued certificates were valid at the time the issue was resolved? Has an audit been carried out?


Reproducible: Didn't try

Steps to Reproduce:
1. Create account at StartCom
2. Complete domain verification process upto the email selection stage
3. Send an email of your choice, rather than one under control of the victim
4. Respond to probe and issue certificates for the victim's domain



Actual Results:  
Certificate for victim's domain is issued

Expected Results:  
User input is validated against the list of email addresses proposed

Comment 1

[Eddy Nigg (StartCom)]

Please don't create accounts solemnly for testing purpose. Sam, your steps to reproduce obviously don't work. The issue you are referring to involved a bug in the user input checking and a report has been published after detection of the problem. The issue has been discussed and covered at the mailing lists of Mozilla.

Comment 2

[u88484]

I agree on the not creating test accounts but we should still get confirmation and final word on what all happended/steps taken/and whatever else on bugzilla in all relevant open bugs.

Comment 3

[Eddy Nigg (StartCom)]

Attachment: Critical event report as published

Comment 4

[Eddy Nigg (StartCom)]

(In reply to comment #2)
> I agree on the not creating test accounts but we should still get confirmation
> and final word on what all happended/steps taken/and whatever else on bugzilla
> in all relevant open bugs.

Agreed! This particular issues has been handled at the crypto mailing list sufficiently (as no further actions were suggested). StartCom was also under audit during that time and the procedures and action items of StartCom were confirmed accordingly in the audit. StartCom continues to be audited on a yearly basis.

The important thing perhaps here to note is, that StartCom has different layers of defenses in place (even in cases of a bug in its systems) and acted according to the procedures for such incident handling correctly. A scan and additional verifications at that time of the then valid certificates revealed no other failed validations - this was not noted in the publicly published report because it was performed a bit later.

Comment 5

[Sam Johnston]

> Please don't create accounts solemnly for testing purpose.

From the original report: "Reproducible: Didn't try".

In any case while both insightful and entertaining your "critical event report as published" doesn't answer the question. The flaw did not trigger "failed validations" (which was precisely the problem!) so how were your "scan and
additional verifications" used to guarantee that the vulnerability had not been misused prior to discovery?

Comment 6

[Eddy Nigg (StartCom)]

The email addresses used to send for the validations are logged. A check found no validations which weren't either for the administrative mail accounts or for listed emails in the whois entries.

I'm glad the report was entertaining for you and I didn't expect anything different from you.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

When a serious question arises about a CA in Mozilla's root CA list, 
and a decision is made (either to take remedial action, or NOT to take any 
action), it would be wise for Mozilla to record that decision here in bugzilla.

It appears that groups.google.com now limits searches of mozilla.dev.* groups
to only the last 6 months, regardless of the date range you choose.  
Consequently, the past discussions of this subject are no longer findable 
with the search abilities of groups.google.com.  The Mozilla community needs
a longer lasting searchable record of such decisions.

Comment 8

[Eddy Nigg (StartCom)]

Thunderbird is a fantastic news reader....I simply downloaded the last 5000 messages and found the last statement from Frank Hecker on this issue:

1. I appreciate your being proactive in posting about the StartCom problems that were discovered and getting them fixed in a timely manner. I wish more CAs would be more forthcoming about things like this.

2. I understand that what happened in the case of StartCom was not exactly the same as what happened in the case of Comodo/CertStar. However it's part of web security basics to assume that whatever a client sends to a server is untrusted and must be (re)verified on the server side to forestall potential attacks (e.g., SQL injection, etc.) So IMO you get points for prompt disclosure and fixes, but in the end you messed up just like Comodo and CertStar did.

3. To paraphrase what Nelson (?) wrote, "bugs happen". I don't think the PKI/CA system is so fragile that it necessarily comes tumbling down whenever a CA or RA makes a mistake. (If it really is that fragile then we have bigger problems than those we're discussing here.) From a policy point of view I think our interest is having CAs acknowledge problems and fix them in a timely manner, both in terms of revoking certs when needed and also in terms of addressing any underlying root causes.

4. In line with the previous point, I am not planning to recommend removal of StartCom's root over this incident, both because the issue been addressed by StartCom and also because it appears to be an isolated incident that does not indicate any larger problem of incompetence or maliciousness.

Comment 9

[u88484]

Thanks Eddy.  Just looking for an official response from Mozilla and then we should be done here.

Comment 10

[Sam Johnston]

> The email addresses used to send for the validations are logged. A check found
no validations which weren't either for the administrative mail accounts or for
listed emails in the whois entries.

Ok that's the kind of thing I was looking for (actually I was expecting that you logged the addresses offered and were able to match them up with the ones furnished but this is much of the same). I don't like that we just have to trust you about this (rather than an accountant/auditor) - not because I don't but because it's too easy to CYA without oversight.

> I'm glad the report was entertaining for you and I didn't expect anything different from you.

Surely you appreciate the irony of going after a competitor only to get caught with the back door open by a well-intentioned bystander, and then report "The attacker proved to be cooperative, evidence was recorded and criminal charges currently not taken". Funny stuff even now.

Thanks for clarifying... FWIW I'm satisfied.

Sam

Comment 11

[Eddy Nigg (StartCom)]

(In reply to comment #10)
> Surely you appreciate the irony of going after a competitor only to get caught
> with the back door open by a well-intentioned bystander

The irony is actually that this event happened BEFORE _I_ ran into Comodo. I wouldn't have done that either, wouldn't it be for the fact that _I_ received an email pretending _I_ had to renew my certificate with _THEM_. Just check the chronology of events. BTW, Mike Zusman is a known security specialist and not a by-stander.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

The message that Eddy quoted in comment 8 may be seen at 
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/67cbe7ae01a8cb0c?dmode=source

Comment 13

[Eddy Nigg (StartCom)]

(In reply to comment #10)
> I don't like that we just have to
> trust you about this (rather than an accountant/auditor) - not because I don't
> but because it's too easy to CYA without oversight.

Of course I wouldn't either if I'd belong to a CA whose coach/auditor just ran away after years of relentless efforts without success. 

> ...and then report "The
> attacker proved to be cooperative, evidence was recorded and criminal charges
> currently not taken". Funny stuff even now.

Of course that's fun stuff for you which shows your overall understanding on the subject. Identification and legal steps are part of the defined procedures of CAs - it's a technical part for cases involving non-adherence and breach of the subscriber obligations.

Even though I agree that failures by CAs should be clarified (which has been done at the crypto mailing list more than six month ago - it's not a recent event as claimed in the opening of the bug), it seems that you are more interested in dragging StartCom through the mud (it's not your first time IIRC). My advice is you'd better check out the wooden beam in your own eye before pointing to the splinters in that of others.

Comment 14

[Sam Johnston]

Wow, here I was thinking this was resolved and yet the hilarity ensues.

I honestly have no idea what you're talking about and in any case all but gave up on PKI as an acceptable/sensible solution a while back. The fact that we have no way to verify a CA's claims regarding discovered vulnerabilities (let alone those we don't yet know about) is particularly problematic, and it's disappointing that incident resolution isn't stronger (for example, requiring a visit from a third party). Furthermore, any CA found concealing information about vulnerabilities should be immediately and permanently be removed from the roots, thus providing significant disincentive for shenanigans where there currently is none.

As for the discussion on the crypto list, it's already been pointed out that such things belong in Bugzilla and in any case the bug calls for important clarifications that were not previously provided.

Oh and the fact that "Mike Zusman is a known security specialist" is all the more reason not to make stupid comments about recording evidence and not ruling out criminal charges - this may work on your customers but to those who know better you look like a clown. While it may have been discovered just before your Comodo disclosure, it was published in response to it "in the interest of full-disclosure".

Comment 15

[Eddy Nigg (StartCom)]

What you didn't understand is, that it's all about the procedures and controls in place and their effectiveness when a vulnerability is discovered, it's much less about the vulnerability itself.

Also you perhaps forgot that this is an internal report which we decided to make public (un-edited). It wasn't meant to be for public consumption....besides that, I still don't understand what's so stupid and funny about it. Never mind...

Comment 16

[Frank Hecker]

(In reply to comment #7)
> When a serious question arises about a CA in Mozilla's root CA list, 
> and a decision is made (either to take remedial action, or NOT to take any 
> action), it would be wise for Mozilla to record that decision here in
> bugzilla.

The quote attributed to me in comment #8 is accurate, and was meant to be my official word on the subject.