Closed Bug 1769000 (CVE-2023-0430) Opened 2 years ago Closed 2 years ago

Message signed with revoked S/MIME certificate shown as correctly signed

Categories

(MailNews Core :: Security: S/MIME, defect)

Thunderbird 91
defect

Tracking

(thunderbird_esr102 fixed, thunderbird110 fixed)

RESOLVED FIXED
111 Branch
Tracking Status
thunderbird_esr102 --- fixed
thunderbird110 --- fixed

People

(Reporter: pmenzel+bugzilla.mozilla.org, Assigned: KaiE)

References

(Regression)

Details

(Keywords: regression, sec-high)

Attachments

(1 file)

Steps to reproduce:

Use Debian sid/unstable with thunderbird 1:91.8.1-1, and view a message signed with a revoked S/MIME certificate.

Actual results:

The message is displayed a correctly signed despite the certificate being revoked.

Expected results:

The message should be shown as incorrectly signed.

$ openssl ocsp -issuer x-chain.pem -issuer GEANT_Personal_CA_4.pem -cert x.pem -url http://GEANT.ocsp.sectigo.com
WARNING: no nonce in response
Response verify OK
x.pem: revoked
	This Update: May  9 04:30:28 2022 GMT
	Next Update: May 16 04:30:28 2022 GMT
	Revocation Time: Dec  7 11:21:35 2021 GMT
Component: Untriaged → Security: S/MIME
Product: Thunderbird → MailNews Core

Any hints how to debug this by setting some environment variables?

(In reply to Paul Menzel from comment #1)

Any hints how to debug this by setting some environment variables?

Flags: needinfo?(kaie)

I haven't seen this report earlier, sorry.

I'd consider this a serious bug.

I would need to see an example where the signing certificate hasn't expired yet, but has been revoked.
I'm afraid that the signing certificate from your example has expired in the meantime?

Flags: needinfo?(kaie)

I would have hoped there are publicly available test certificates to test this.

Anyway, the certificate is actually still valid. If you send me an email with your S/MIME certificate, and can make that message available to you.

Paul, thanks, I am able to confirm the bug.
I'm currently evaluating the best way to fix it.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → kaie
Status: NEW → ASSIGNED

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/77d11965ebbb
Re-enable OCSP checking when verifying S/MIME signature certificate. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

Thank you for the fix. Some questions:

  1. As there is no elaborate commit message, could you please elaborate here, which commit disabled OCSP checking, so it’s clear in what version the problem was introduced?
  2. Is this a security issue? If there is a security team, does it need to be contacted to coordinate backporting this? Does a CVE need to be assigned?

Yes, I consider it a security issue, we intend to backport it to the esr102 branch soon, and will issue a CVE.

Tom, can you please assign a CVE?

Flags: needinfo?(tom)

The regression was apparently caused by bug 1500003.
The first release with this regression was version 68.0

Regressed by: 1500003
Alias: CVE-2023-0430
Flags: needinfo?(tom)

Given that comm-central is currently in an instable state (after the "ash" repository merge), I suggest that we uplift this immediately to beta for testing. I think the code should be safe for comm-esr102, too.

Comment on attachment 9313158 [details]
Bug 1769000 - Re-enable OCSP checking when verifying S/MIME signature certificate. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): bug 1500003
User impact if declined: wrong digital signature security status for messages that were signed using a revoked S/MIME certificate
Testing completed (on c-c, etc.): Manually. We have no automated tests covering requests to live OCSP servers.
Risk to taking this patch (and alternatives if risky): I think it's low. In a debug build, the worst is a controlled deliberate crash. In an optimized build, the use of the incorrect (main) thread will be detected (in mozilla::pkix::Result DoOCSPRequest) and an error "cannot perform OCSP" will be returned - that's the same level of today's not attempting OCSP, which means the patch cannot make things worse in an optimized build, IMO.

Attachment #9313158 - Flags: approval-comm-esr102?
Attachment #9313158 - Flags: approval-comm-beta?
Keywords: sec-high
Target Milestone: --- → 111 Branch

Comment on attachment 9313158 [details]
Bug 1769000 - Re-enable OCSP checking when verifying S/MIME signature certificate. r=darktrojan

[Triage Comment]
Approved for beta
Approved for esr102, pending beta release

Attachment #9313158 - Flags: approval-comm-esr102?
Attachment #9313158 - Flags: approval-comm-esr102+
Attachment #9313158 - Flags: approval-comm-beta?
Attachment #9313158 - Flags: approval-comm-beta+

Thank you, it works correctly with Mozilla Thunderbird 102.7.1:

This message includes a digital signature, but the signature is invalid.

The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate.

German:

Diese Nachricht enthält eine digitale Unterschrift, aber die Unterschrift ist ungültig.

Das Zertifikat, das zum Unterschreiben der Nachricht verwendet wurde, wurde von einer Zertifizierungsstelle herausgegeben, der Sie für diese Art von Zertifikaten nicht vertrauen.

Thank you for all involved.

(I created bug 1812295 1 regarding the message, which could be more specific.)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: