Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 403582 - Failure to detect insecure embedding of SWF movie
: Failure to detect insecure embedding of SWF movie
Product: Core Graveyard
Classification: Graveyard
Component: Security: UI (show other bugs)
: unspecified
: All All
: P3 normal (vote)
: ---
Assigned To: Kai Engert (:kaie)
Depends on:
Blocks: lockicon
  Show dependency treegraph
Reported: 2007-11-12 23:26 PST by Adam Barth
Modified: 2016-09-27 13:03 PDT (History)
10 users (show)
mbeltzner: wanted‑next+
mbeltzner: wanted1.9.0.x+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description Adam Barth 2007-11-12 23:26:55 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071025 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071025 Firefox/

If an HTTPS page embeds a SWF movie over HTTP, the browser fails to detect mixed content.  SWF movies can script the embedding page.  Insecure Java applets go similarly undetected.

This bug is particularly insidious because site developers often rely on the browser to detect mixed content in their site.  For example, at least one major bank includes an insecure SWF on their login page, allowing an active network attacker to steal their customer's passwords and second factors of authentication.

Reproducible: Always

Steps to Reproduce:
Steps to reproduce:
 1) Navigate to <>.
 2) Notice the insecure applet can script the page.
 3) Notice the lack of a slash over the lock icon.
Actual Results:  
Browser treats page as secure (does not degrade to mixed content).

Expected Results:  
Browser should degrade page to mixed content.
Comment 1 :Gavin Sharp [email:] 2007-11-13 10:32:49 PST
This is related to bug 369503, although that one complains about security UI not being updated to reflect insecure connections made by the plugin itself, rather than not updating because of insecure loading of the plugin file.

I think we probably load plugins in the background, as we do for XMLHTTPRequest loads and some image loads, so this might depend on bug 305284/bug 135007.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2007-11-13 12:24:04 PST
We don't do plugin loads in the background, no.

That said, there are at least three different plugin loading codepaths.  :(  Can someone trace through the code here to see exactly where we do the AsyncOpen on the nsHttpChannel?  I'd do it if gdb would let me breakpoint there....

I suspect this may be a PSM bug, not a plug-in bug.
Comment 3 Damon Sicore (:damons) 2007-11-14 12:12:20 PST
Boris, what do you think the priority should be on this?  Note:  We're up to about 175 P3 bugs here.  Need to be super rational about how we prioritize things from this point on.  I don't see this making beta 2.  So, we need to decide Beta 3 or final.  Thoughts?
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2007-11-14 12:44:18 PST
ccing Daniel and Kai for their thoughts.  The answer sort of depends on how reliable the security UI is now and how seriously we take issues with it...

I suspect any change here would be somewhat risky, but can't really justify rating this above P3, I don't think.
Comment 5 Damon Sicore (:damons) 2007-11-15 11:55:14 PST
+'ing and making P3. 
Comment 6 Johnathan Nightingale [:johnath] 2007-11-21 10:26:16 PST
Jonas assigned this to me, but I agree with boris in comment 2 that this is probably an NSS/PSM bug with the kinds of updates we get in chrome through our WebProgressListener.  We've seen mixed content breaking in other bugs too, as gavin mentions.  I think Kai is looking at this brokenness as a result of bug 402574, which also deals with broken signalling between crypto and chrome.

Re-directing to sec:ui anyhow, since it seems likely that it has more to do with how we're handling the security of the channel than with the plugin in particular.  Judging from the symptoms alone, and without knowing the code involved, it feels like we have one or two bugs here that are responsible for a dozen different chrome-misidentifying-security-level reports.
Comment 7 Brandon Sterne (:bsterne) 2011-07-25 13:59:48 PDT
This has been fixed, though I don't know when.

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