Last Comment Bug 330037 - Embed Propertypage Remote Compromise (version 2)
: Embed Propertypage Remote Compromise (version 2)
Status: RESOLVED FIXED
[sg:moderate]
: fixed1.8.1, verified1.8.0.4
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
: -- critical (vote)
: ---
Assigned To: Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-10 07:22 PST by Paul Nickerson
Modified: 2008-10-17 15:49 PDT (History)
10 users (show)
dveditz: blocking1.7.14?
dveditz: blocking‑aviary1.0.9?
dveditz: blocking1.8.0.4+
dveditz: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (299 bytes, text/html)
2006-03-10 07:24 PST, Paul Nickerson
no flags Details
patch (1.68 KB, patch)
2006-03-10 08:55 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
bzbarsky: superreview+
dveditz: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Review
1.0.x version (1.35 KB, patch)
2006-06-13 14:56 PDT, Alexander Sack
asac: review? (caillon)
Details | Diff | Review

Description Paul Nickerson 2006-03-10 07:22:41 PST
The patch from the previous advisory can be circumvented if the following two changes are made:
1) The embed element is shown on a javascript page
2) The executed javascript accesses chrome using it's full priviledges to the opener object

This can be exploited using a small amount of user interaction which will likely occur given the right social engineering.
Comment 1 Paul Nickerson 2006-03-10 07:24:00 PST
Created attachment 214672 [details]
testcase

Navigates to a javascript:"content" page. Click on the broken embed box and press manual install. An alert will be shown in the chrome window indicating the execution of arbitrary script.
Comment 2 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-03-10 08:55:13 PST
Created attachment 214683 [details] [diff] [review]
patch

Well, this fixes it for me, by moving some code in nsScriptSecurityManager.cpp.
Comment 3 Doron Rosenberg (IBM) 2006-03-10 10:01:25 PST
The code in the plugin finder is:
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/plugins/content/pluginInstallerWizard.js#566

This is probably a stupid question, but would the evalInSandbox stuff (http://developer.mozilla.org/en/docs/evalInSandbox) be any better for this code?
Comment 4 Daniel Veditz [:dveditz] 2006-03-10 14:23:58 PST
Another example of the evils of string URL compares rather than principal compares.
Comment 5 Daniel Veditz [:dveditz] 2006-03-10 14:25:14 PST
Comment on attachment 214683 [details] [diff] [review]
patch

This is good as a band-aide. r/sr=dveditz
Comment 6 Doron Rosenberg (IBM) 2006-03-10 15:43:25 PST
I filed bug 330102 on myself to switch the code to nsIPrincipal 
Comment 7 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-03-14 16:22:12 PST
Sorry, but do I need sr+ for the patch?
Comment 8 Boris Zbarsky [:bz] 2006-03-14 16:49:47 PST
Comment on attachment 214683 [details] [diff] [review]
patch

Generally, yes.  ;)
Comment 9 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-03-15 03:04:03 PST
Checking in caps/src/nsScriptSecurityManager.cpp;
/cvsroot/mozilla/caps/src/nsScriptSecurityManager.cpp,v  <--  nsScriptSecurityMa
nager.cpp
new revision: 1.289; previous revision: 1.288
done

Checked into trunk.
Comment 10 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-03-23 17:27:29 PST
Checked in on the 1.8 branch.
mozilla/caps/src/nsScriptSecurityManager.cpp; new revision: 1.266.2.10;
Comment 11 Daniel Veditz [:dveditz] 2006-04-03 12:31:04 PDT
Comment on attachment 214683 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=dveditz for drivers
Comment 12 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-04-27 19:37:52 PDT
mozilla/caps/src/nsScriptSecurityManager.cpp 	1.266.2.7.2.5
Comment 13 Jay Patel [:jay] 2006-05-11 13:16:16 PDT
v.fixed on 1.8.0 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 with testcase.
Comment 14 Daniel Veditz [:dveditz] 2006-05-30 22:58:23 PDT
Impact lowered to "moderate" given the user interaction required. A legit "manual" install button is used to download and install and that could be malware as well, the only difference is this exploit removes one last chance for the user to think better of running the downloaded install.
Comment 15 Alexander Sack 2006-06-13 14:56:39 PDT
Created attachment 225481 [details] [diff] [review]
1.0.x version

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