looks like pdp is running w/ it as a model changing the way we use computers...?? he doesn't say so, but it sure sounds similar...
there have been a number of vulns (carpet bombing, etc) reported so far, but i'm not too worried about those. this is beta software, so we have to expect there will be some oversights which can be exploited. so, based on what we know today, how do we see the design changes which will be present in the final release impacting security?
[process isolation]
process isolation may defeat some client side attacks... are cookies isolated to their tabs? if so, browsing separate domains via tabs may offer some protection from cookie stealing and CSRF.
this is kinda out there, but since processes are isolated, watchdogs on memory and proc usage (mb io?) may be able to identify 0day-ish attacks which are consuming resources...? that's a long shot tho...
[incognito]
incognito mode seems nice on many levels. i've heard jokes about how it's just a pr0n-mode, but there are many times i browse around online where i don't want to allow any web site to write anything to disk (ie: reading headlines on digg). i don't expect anything hostile to happen, but there are attacks (ie: malicious ads/apps via 3rd party content) which could be bumped into. why not use incognito for daily-browsing? might it be a reasonable alternative to running no-script, ad-block, cookie-safe, and flash-block?
i do question whether or not this is read-only, or just a more restricted jail. it seems like temporary file writes will still be required, but i'm not quite sure...
[attack vectors]
so what attacks look possible under this design?
so if users drag pop-ups out, and they get promoted to their own windows, how does that impact sec? does all retained information (cookies, history, etc) propogate to the new process for the pop'd out tab?
sandboxing seems very very good... lots of badness (malicious jscript stealing creds, keylogging, etc) is mitigated in this model. but can it be attacked? if each process is isolated, can an escalation attack upward against the master chrome process succeed in breaking the security model? that brings the question of how much chrome security depends on the isolation model being maintained (ie: how bad are things if isolation is gone; are we just back to where we were w/ browsers pre-chrome? or is it worse b/c we assumed we'd be isolated and so didn't take other sec steps)
the idea of tracking what a user has actually requested is pretty nifty. reminds me of packet-filters (old browsers) vs stateful firewalls (chrome). the comic here points out that plugins don't conform to this model, so those may be a weak-point. another issue will be whether or not a process can create a false user request. can a malicious pwnt tab process mimic some type of user request, either in the local tab or in another tab process.
sandboxing plugins reduces risk, but they can now attack upward as well? will a flaw in a plug-in feature (ie: quick-time, flash) potentially open the chrome process to attack?
another interesting tidbit in the diagram is that the chrome process links pages to plugins. can this be abused somehow? can plugins associate themselves w/ alternate pages? what makes a process eligible to be linked to a plugin process? etc etc etc...
that's all i've got for now. chrome seems to offer some nifty and refreshing looks at browser design.
No comments:
Post a Comment