Hmm... coffee kicking in... to answer my own question, since wpad
interception would probably be DNS based, the attacker could also just use
the same approach to intercept specific hostnames for plaintext HTTP. even
with PAC, the attacker wouldn't have much luck intercepting HTTPS, so the
attack surface doesn't seem any larger with PAC than it already is for
plaintext HTTP.
-Darin
On Wed, Feb 18, 2009 at 8:00 AM, Darin Fisher <da...@chromium.org> wrote:
> Right... I meant the particular vector of faking the proxy auto config file
> to achieve HTTP interception. That Windows has "auto detect proxies"
> enabled by default would seem to make this an easy target for hackers.
> -Darin
>
>
>
> On Tue, Feb 17, 2009 at 10:16 PM, Adam Barth <aba...@chromium.org> wrote:
>
>> No one else has a sandbox for their JavaScript engine. ACE in their
>> JS engine is game over.
>>
>> Adam
>>
>>
>> On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher <da...@chromium.org> wrote:
>> > I wonder why this hasn't gotten much attention in other browsers...
>> > -Darin
>> >
>> > On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth <aba...@chromium.org>
>> wrote:
>> >>
>> >> Hi Eric,
>> >>
>> >> On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman <ero...@chromium.org>
>> wrote:
>> >> > My goal is to do all the work necessary to get V8-PAC resolving
>> >> > working in the browser process first.
>> >>
>> >> That sounds like a good plan, but I think we should implement the
>> >> security mitigation as a second step.
>> >>
>> >> > The logic goes something like:
>> >> > * To exploit V8 you must be running an evil PAC script.
>> >> > * If you are running an evil PAC script, you are already screwed.
>> >>
>> >> The situation is a little more subtle than this. Here is how I think
>> >> about it:
>> >>
>> >> Threat Model:
>> >>
>> >> 1) You are using the browser on an untrusted network. Likelihood:
>> >> Routine (users routinely surf the Web on untrusted wireless networks,
>> >> for example in coffee shops and in airports).
>> >>
>> >> 2) V8 has an exploitable arbitrary code execution vulnerability.
>> >> Likelihood: Will occur at some point. Window of Vulnerability: One
>> >> patch cycle (exploitable ACEs in V8 are P0 bugs).
>> >>
>> >> Designs:
>> >>
>> >> 1) PAC in renderer process: Universal cross-site scripting. The
>> >> attacker can exploit V8, but the sandbox prevents the attacker from
>> >> reading or writing your hard drive. Severity: High.
>> >>
>> >> 2) PAC in browser process: Arbitrary code execution. The malicious
>> >> PAC script can now install malware on the user's machine. Severity:
>> >> Critical.
>> >>
>> >> Conclusion:
>> >>
>> >> Running PAC scripts in the browser process elevates the severity of a
>> >> reasonable chunk of attack surface (ACE in V8) from high to critical.
>> >>
>> >> Recommendation:
>> >>
>> >> Ideally, we would run the PAC script in a dedicated sandboxed process.
>> >> This would prevent a compromised PAC process from doing much of
>> >> anything. Short of that, we should run PAC scripts in the renderer
>> >> process.
>> >>
>> >> > The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic!
>> >>
>> >> This is the same as universal cross-site scripting and is a
>> >> high-severity vulnerability. Being able to install malware on the
>> >> user's machine is more severe (e.g., critical).
>> >>
>> >> > All they really need to do is substitute the next EXE you download
>> >> > with the code they want to execute, and voila.
>> >>
>> >> This requires user interaction. Specifically, the user has to confirm
>> >> the corrupted download. Moreover, this attack vector is present
>> >> regardless of a vulnerability in V8 (i.e., ability 2 above) because an
>> >> untrusted network can do this already (i.e., just with ability 1
>> >> above).
>> >>
>> >> Adam
>> >
>> >
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
