Or maybe it has? It looks like WinHTTP can perform PAC lookup
out-of-proc... maybe only under Vista.
-Darin
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
-~----------~----~----~----~------~----~------~--~---
