353535 - [mail apps] Delayed UI update caused by OCSP may cause incorrect S/Mime display

Status: RESOLVED WONTFIX

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

Description

[Kai Engert [:KaiE:]]

Enable OCSP
Receive a signed message that was signed using a certificate that specifies an OCSP responder.

When you click on such a message, the message will displayed, and the background processing will start an asynchronous OCSP check.

If you wait, after about a second the UI will get updated with the signature status - good pen or broken pen.

The above is the working case.
In order to see the bug, do the following:

- click that signed message
- quickly click on a different message that is not signed, not encrypted


What we have:
Once the initial OCSP check is done, you'll get the pen icon on that plain message.


What we want:
We need to make sure we do not display signature status information on the wrong message.
At the time the OCSP check is ready, we need to verify the message displayed in the UI is still the one that triggered the OCSP request.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I'm not immediately sure it's exploitable, but it's a serious security error,
applying crypto security results to the wrong message!

Comment 2

[Mike Schroepfer]

Not sure if this is a core or mailnews issue - so taking off the 1.9 blocker list.  Please re-nom if I'm wrong...

Comment 3

[Kai Engert [:KaiE:]]

Renominating for clarification.

Mike or drivers, I think this should block 1.9, but only mail apps that are based on 1.9

Is there a way to express "blocks 1.9 for mail" without being in the way for your Firefox blocker list?

Maybe you should exclude component "Security S/Mime" from your bugzilla queries for firefox, so this bug could remain in the blocking-1.9 state?

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Wouldn't block 1.9 for this, but we'd take the patch if there is one for this.

Comment 5

[Lucas Adamski [:ladamski]]

Marking as sg:moderate since it involves spoofing of authentication information but mitigated by the fact that it requires user to open a malicious email right after a legitimately signed one with specific timing.

Comment 6

[Al Billings [:abillings - ex-MoCo]]

This is effectively a feature request involving significant UI work that hasn't been done in nearly 8 years. As part of Critsmash, I'm making an assumption that this work, after this many years and TB's current status, will not be done. I am "won't fixing" it as a result. If you think that this work will be done, please re-open and assign to a developer to do.