297877 - PAC scripts can reach out of sandbox via myIpAddress.__parent__ and such

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I'm not sure this is exploitable in either the trunk or the branch, so it might
be a false alarm, but they can certainly reach up and mutate objects in Deer
Park 1.1a1.  I'll try to put a test case together tomorrow, but there's
definitely some  testing we should add to our repertoire.  (I don't think my
evalInSandbox changes will make a difference here either way, but the beefed-up
checkAccess calling pattern that just landed might.)

Comment 1

[Darin Fisher]

So, I don't think this is a security concern.  The PAC script can already direct
your browser to violate many of its security restrictions.  We implicitly trust
the PAC script because it is configured by the user (or a sys-admin).  There's
no need to mark this security sensitive in my opinion.

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

With WPAD, it's only implicitly configured by the user (or his delegate); if you
end up on the wrong wireless network you can get some random PAC loaded pretty
quickly.  That's why I thought we might consider it sensitive, but I'm happy for
it to not be.

Comment 3

[Darin Fisher]

Right, I mean... a PAC script can re-route all of your network requests to
whatever server it likes pretending to be the server you requested.  Granted,
this doesn't apply to HTTPS traffic, but it still assumes a great amount of
trust on the part of the PAC origin.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Right, though I might be surprised to discover that I'm trusting the PAC site to
"not execute arbitrary code" vs. "not snoop on traffic that travels in the
clear".    In fact, I think I would be quite surprised.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not blocking beta or 1.5

Comment 6

[benc]

What is the impact of the problem w/ myIpAddress?

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

How do you mean?  The impact is as described in this bug: the script can manipulate objects outside the prescribed "sandbox" environment.

I suspect it's also fixed by one of mrbkap's patches for 1.5.0.4, but I forget which.  He'll know and mark the dep, I have faith!

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

With the checkin for bug 319263, there are no known ways to reach out of the sandbox into the calling chrome code. In particular, <foo>.__proto__, <foo>.__parent__, and (the troublesome) foo.valueOf.call(null) paths are access checked. I'll open a new bug on the underlying problem (unsound security practices while using evalInSandbox), but I believe this bug, as filed, is either FIXED or INVALID.

It's also worth noting, for posterity that dnsResolve and alert were also paths, just as myIpAddress was.

I'll mark this bug as FIXED.