Hi Eric, On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
