I wonder why this hasn't gotten much attention in other browsers... -Darin
On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
