tag:blogger.com,1999:blog-13756280.post222789123518256716..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: Sandboxing: Welcome to the Dawn of the Two-Exploit EraJeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-13756280.post-26560408527331361752016-02-08T16:28:25.833-08:002016-02-08T16:28:25.833-08:00Jim - thanks for your comment! :)
Jim - thanks for your comment! :)<br />Bobhttps://www.blogger.com/profile/15364701932171989276noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-52250656791270746772011-01-04T10:52:13.452-08:002011-01-04T10:52:13.452-08:00You need at least 2 bugs to exploit, but not neces...You need at least 2 bugs to exploit, but not necessarily in the same application.<br /><br />Some sandbox designs allow you to hop into another sandbox. For example, code running in the IE7/8/9 sandbox can open a handle to the Adobe Reader X sandbox and inject code in that sandbox. So you could escape by exploiting one bug in IE and one bug in Reader. Makes the attack surface larger.Didier Stevenshttp://blog.DidierStevens.comnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-8125773033886539452010-12-21T09:42:16.169-08:002010-12-21T09:42:16.169-08:00http://www.gdc4s.com/content/detail.cfm?item=35a99...http://www.gdc4s.com/content/detail.cfm?item=35a995b0-b3b7-4097-9324-2c50008b3a75Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-26231256422718219622010-12-20T16:57:52.861-08:002010-12-20T16:57:52.861-08:00Microsoft has had a sandbox in IE since IE7 on Win...Microsoft has had a sandbox in IE since IE7 on Windows Vista (2006 timeframe, see link below). By today's standards this is a very weak sandbox, but it is a sandbox all the same. Keep in mind that PMIE was retrofitted onto an existing browser whereas, in Chrome's case, Google was able to design their browser with a sandbox in mind. It is fair to say that Adobe Reader should have had the same problems as IE, but I the compatibility concerns from sandboxing Reader are significantly less than IE (hence the weakening of the sandbox in IE's case). Adobe also had significantly lower investment costs for sandboxing Reader because they were able to pick up the sandbox that Google had already developed.<br /><br />In my opinion software dev teams should first invest in FULLY adopting exploit mitigation technologies (DEP/ASLR) before focusing resources on other areas. What we see today is that many software companies (even Microsoft in some cases) have not fully enabled mitigations -- these are the weak spots that attackers generally go after today (such as non-ASLR DLLs). <br /><br />After fully adopting mitigations I agree that product teams should invest in sandboxing. The reason I prioritize this second is because, as I'm sure you will agree, allowing an attacker to execute code is a much weaker defensive position than preventing reliable code execution in the first place. It is fair to say that exploit mitigations won't stop everything, but so far when properly enabled they appear to have had a significant impact on exploit development cost and feasibility.<br /><br />http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspxAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-20032589227784363322010-12-20T15:30:41.494-08:002010-12-20T15:30:41.494-08:00Recently I attended a talk by IBM Researcher Richa...Recently I attended a talk by IBM Researcher Richard Gabriel called “Design Beyond Human Abilities”. Part of his talk discussed an idea from Martin Rinard (MIT) that since software cannot be made perfect, we should accept that software will be defective. And once we accept defective software, we can use it to our advantage, e.g. if we want faster runtime, one method would be to ignore half of the iterations. He did go on to clarify that there’s a difference between “forgiving” and “unforgiving” parts of the code, where you identify that which must always be correct vs. that which can be approximate/wrong (such as the color of a single pixel).<br /><br />Here's his talk in PDF form (see page 17 for the Rinard reference):<br /><br />http://www.dreamsongs.com/Files/DesignBeyondHumanAbilitiesSimp.pdfUnknownhttps://www.blogger.com/profile/12161615228738844434noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-28826057359439432162010-12-20T15:20:01.855-08:002010-12-20T15:20:01.855-08:00@Anonymous: "doomed," nah, everything st...@Anonymous: "doomed," nah, everything still works fine. Sandboxing is a lot about protecting known broken code with something smaller and stronger. Guard an enclosed perimeters rather than all the doors within.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-92179379534061385922010-12-20T13:58:37.361-08:002010-12-20T13:58:37.361-08:00It's not SELinux reinvented again, it's th...It's not SELinux reinvented again, it's the UID reinvented again.<br /><br />Operating systems are supposed to isolate process run as different UIDs (Unix) or SIDs (NT) from each other. Android makes use of this design capability, running each application as a distinct UID.<br /><br />Unfortunately, no kernel is strong enough to actually uphold this most basic guarantee, even though we have been depending on it for decades. Why would a new (likely more complex and featureful) sandboxing mechanism work where the old, simple one has proven unworkable?<br /><br />Although we actually do have some code that is very strong (DJB's comes to mind), I do agree with you that we cannot really expect vulnerability-free code. Since experience shows we also can't expect sandboxing to work, aren't we basically doomed?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-84732028980754492142010-12-20T13:58:16.188-08:002010-12-20T13:58:16.188-08:00Or, longer ago still, with Multics:
"A Hardw...Or, longer ago still, with Multics:<br /><br /><a href="http://www.multicians.org/protection.html" rel="nofollow">"A Hardware Architecture for Implementing Protection Rings"</a> and <a href="http://www.multicians.org/mga.html#AIM" rel="nofollow">the Access Isolation Mechanism (AIM)</a>.Lippardhttps://www.blogger.com/profile/16826768452963498005noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-64717602062643113602010-12-20T13:45:57.632-08:002010-12-20T13:45:57.632-08:00SELinux - reinvented again.SELinux - reinvented again.Anonymousnoreply@blogger.com