jeremiah grossman recently penned a guest post for zdnet extolling the virtues of sandboxing. i've made no secret about the fact that i'm also a fan of sandboxing (though i'm not entirely on board with jeremiah's depiction of it with regards restricting things - that verges too close to behaviour blocking for liking) but the sandboxing jeremiah was referring too was the kind that is built into applications as a feature.
not too long ago posted about sandboxes being added to all sorts of apps and wondered (well, suggested) that such sandbox sprawl might not be the best way to go about things. jeremiah's observation that adding sandboxes to apps changes the game from a one exploit show to a two exploit show made me realize another reason why relying on the application's own sandbox is less than ideal - the attacker knows exactly which sandbox they have to escape from.
by contrast, with a separate stand alone sandbox, an attacker wouldn't necessarily know which sandbox is involved and would then need to develop escape exploits for multiple sandboxes and try the shotgun approach, firing them all at once and hoping for the best.
i do believe i'll be sticking with the stand alone sandbox. it seems to have the tactical advantage.
1 comments:
Another issue with the sandbox-zoo is sandbox-hopping.
Code running in the IE7/8/9 sandbox can inject code in the Adobe Reader sandbox or Microsoft Office sandbox.
If one has an exploit for IE but no IE sandbox bypass, however one has an Adobe Reader sandbox bypass, then one can inject code into Adobe Reader and escape from the Adobe Reader sandbox.
Post a Comment