Closed Bug 353535 Opened 18 years ago Closed 9 years ago

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

Categories

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

1.8 Branch
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: KaiE, Unassigned)

References

Details

(Keywords: regression, sec-moderate, Whiteboard: [kerh-bra][mail apps][sg:moderate][psm-smime][psm-feedback][psm-cve])

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.
Blocks: 157555
Keywords: regression
Whiteboard: [kerh-bra]
I'm not immediately sure it's exploitable, but it's a serious security error, applying crypto security results to the wrong message!
Flags: blocking1.9?
Priority: -- → P3
Whiteboard: [kerh-bra] → [kerh-bra] [mail only]
Summary: Delayed UI update caused by OCSP may cause incorrect S/Mime display → [mail apps] Delayed UI update caused by OCSP may cause incorrect S/Mime display
Whiteboard: [kerh-bra] [mail only] → [kerh-bra] [mail apps]
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...
Flags: blocking1.9? → blocking1.9-
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?
Flags: blocking1.9- → blocking1.9?
Wouldn't block 1.9 for this, but we'd take the patch if there is one for this.
Flags: blocking1.9? → blocking1.9-
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.
Whiteboard: [kerh-bra] [mail apps] → [kerh-bra] [mail apps] [sg:moderate]
Group: core-security
Product: Core → MailNews Core
QA Contact: s.mime
Group: core-security
Assignee: kaie → nobody
Whiteboard: [kerh-bra] [mail apps] [sg:moderate] → [kerh-bra][mail apps][sg:moderate][psm-smime][psm-feedback]
Whiteboard: [kerh-bra][mail apps][sg:moderate][psm-smime][psm-feedback] → [kerh-bra][mail apps][sg:moderate][psm-smime][psm-feedback][psm-cve]
Group: crypto-core-security
Group: crypto-core-security
Group: core-security → crypto-core-security
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Group: crypto-core-security
You need to log in before you can comment on or make changes to this bug.