Yes, exactly. Although there was a hilarious point in time when the guy who registered wpad.com could own the entire Internet.
Adam On Wed, Feb 18, 2009 at 8:17 AM, Darin Fisher <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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 -~----------~----~----~----~------~----~------~--~---
