1. 1 EuroSys 2010, Paris, France Shuo Chen, Hong Chen, Manuel Caballero Microsoft Corporation Purdue University Redmond, WA, USA West Lafayette, IN, USA April 15 th, 2010

2. 2 EuroSys 2010, Paris, France Managing the lifetimes for objects in the memory A difficult task for complex systems Especially true for browsers Expected semantics of browser navigation After a page is navigated away, no object in the page is accessible by future pages. Otherwise, basic security properties can be compromised Visual integrity, document integrity and memory safety Demos …

3. 3 EuroSys 2010, Paris, France Due to the dilemma between the scripting capability, the navigation mechanism and the garbage collection 1. Scripts are allowed to hold references to objects in other pages 2. A page is allowed to be navigated away regardless of whether its internal objects are referenced by other pages. 3. Objects with non-zero reference counts cannot be garbage collected. Page A Page B If objects in page B are garbage collected dangling references, memory corruption. Not garbage collected become residue objects. Page C

4. 4 EuroSys 2010, Paris, France Every browser has the logic trying to ensure that Residue objects cannot be accessible. Unfortunately, the logic is non-trivial, and historically error- prone. Our paper cites several known bugs that are clearly due to incorrect guarding of residue objects. 4 for IE, 3 for Firefox and 1 for Safari Each bug is specific to a browser, but the problem is cross-browser. Despite individual bug reports, the bugs had not been studied as a class. No collective understanding is available.

5. 5 EuroSys 2010, Paris, France We attempt to answer two questions What are the challenges of guarding residue objects? Is it a minor problem or its scope is not well recognized? These bugs have not been prevalent in public vulnerability repositories. What we did We conducted a focused study about IE to understand its guarding logic. We examined the logic using an enumerative test generation approach. We found 5 new bugs of this type in IE. We explained some pitfalls in building the guarding logic.

6. 6 EuroSys 2010, Paris, France

7. 7 ActiveX – the technology to build most browser objects All HTML elements, as well as the HTML rendering engine and the Javascript engine ActiveX object interface AddRef, Release – refcounting Invoke – invocation of a method of an object HTML and Javascript languages have generic mechanisms to load ActiveX objects. In HTML, element In Javascript, obj=new ActiveXObject(...)

8. 8 EuroSys 2010, Paris, France and elements Upon a navigation, the window object persists, but a new document object is switched in. At the C++ level, they are implemented as objects of CWindow and CDocument classes. Class names begin with C by convention. Security based on the object-capability model Object capability model: object A can access object B only if it has a reference to object B.

9. 9 EuroSys 2010, Paris, France Cross-window security check – CWinProxy No reference of a CWindow object should be passed to other windows. Instead, upon a cross-window referencing, an object of CWinProxy class is created and passed out. CWinProxy enforces security checks. Each object of CWindow, CDocument or CWinProxy has a Boolean flag validity If validity == false, then the object should not be accessed. Main question The mechanism seems simple to enforce. What can go wrong in the actual browser implementation?

10. 10 EuroSys 2010, Paris, France

11. 11 EuroSys 2010, Paris, France Our tactic for test case generation A tool to obtain the memory-level insights into the test cases

12. 12 EuroSys 2010, Paris, France We generate test cases by Enumerating different inner objects Enumerating different ways of object hosting Enumerating different ways of navigations Persistent window Inner object Navigational window (1) Reference to the inner object (2) navigate the navigational window

13. 13 EuroSys 2010, Paris, France We log important operations of the browser Construction/destruction/addRef/release of the objects of CWindow/CDocument/CWinProxy Validity changes of these objects The navigation We built an analysis tool to obtain the following insights After the navigation, which objects are in the memory (and their refcounts)? What are their validity flags? Which are the remaining references and who are holding them?

14. 14 EuroSys 2010, Paris, France

15. 15 EuroSys 2010, Paris, France The test case: the inner object is a window Persistent window Navigational window Observations The inner window stays in the memory after the navigation of the navigational window, although invalidated When the inner window is created by createPopup(), it remains visible. Damage to the visual integrity E.g., the demo of the EuroSys banner. Inner window var ref = InnerWin;

16. 16 EuroSys 2010, Paris, France The test case: the inner object is a method of the inner window Persistent window Navigational window Observations The CWindow object of the inner window is invalidated, but its CWinProxy object held by the persistent window is not. The C++ object representing the method contains a polymorphic pointer whose real type is CWinProxy, not CWindow. The method is allowed to run after the navigation. Result: a script in the old page can survive the navigation. var ref = InnerWindow.setTimout; Inner window A method of the window

17. 17 EuroSys 2010, Paris, France The test case: the inner window is hosted in another HTML engine. Remember that the HTML engine itself is an ActiveX object, and the HTML allows loading an ActiveX object into the page. Persistent window Navigational window Observation The inner window is not invalidated after the navigation of the navigational window Result: a script in the inner window can survive the navigation. Another HTML engine The inner window is rendered by another HTML engine! Inner window

18. 18 EuroSys 2010, Paris, France Erroneous refcounting A CWinProxy object loses one extra refcount when the window is navigated away. This results in a dangling reference. EIP is corrupted. Microsoft patched this bug in a hotfix. Partially destroyed data structure in a valid object A CWindow object is still valid after navigation But some members in the object have been destroyed. It results in an invalid pointer value.

19. 19 EuroSys 2010, Paris, France At the conceptual level – seemingly simple Residue objects should be invalidated, and the invalid objects should not interfere with the users browsing experience. At the implementation level – difficult to be error-proof Which objects to stay or to remove – need to be precise. Whose references are held by whom – any unexpected reference path? How to correctly set the validity for every affected object? E.g., even in the cross-HTML-engine situation How to perform the validity checking appropriately? E.g., despite the polymorphism in the program. …

20. 20 EuroSys 2010, Paris, France Implementing browsers using Java, C#, etc, rather than C++? It will eliminate memory bugs, but other bugs are unaffected. Placing each window in a process? It will mitigate the exploits of memory bugs, but other bugs do not involve any raw memory access, and thus are unaffected. Promising direction To think about partitioning objects in different processes And, to examine the HTML DOM policies and implementation Examples: OP browser of UIUC and Gazelle browser of Microsoft Research

21. 21 EuroSys 2010, Paris, France We formulated a class of previously reported security bugs as the residue object problem. The literature shows that it is a cross-browser problem. We studied IE, which gives evidences to show that The logic of guarding residue objects is non-trivial, despite the seemingly simple policy at the conceptual level. Many unknown bugs may still exist in major browsers. The scope of the problem has not been well recognized.