Browser Security: A New Research Territory

Browser Security: A New Research Territory Shuo Chen Cybersecurity and Systems Management Group Microsoft Research, Redmond, WA

Outlines • Preamble • A little marketing about our research group • Two browser security projects that I am working on • Browser visual spoofing (with Jose Meseguer, Ralf Sasse, Helen J. Wang and Yi-Min Wang) • Cross domain security violation (a brief introduction) • Conclusion: Browser/web security research is exciting

A little marketing about our research group • Cybersecurity and Systems Management Group • http://research.microsoft.com/csm/ • Current security projects • HoneyMonkey: client-side honeypots to find malicious websites • SearchRanger: finding spam websites that try to promote junk pages into top positions in search engines. • Browser security (this talk) • Current systems management projects • FDR (Flight Data Recorder): always-on tracing of all interactions between Windows apps and configurations. Deployed on MSN production servers. • WARDEN: machine learning analysis of HTTP logs to troubleshoot Internet connectivity problems. • AjaxScope: remote monitoring/runtime analysis of web apps on end-user desktops.

A little marketing about our research group (cont.) • Manager/primary contact: Yi-Min Wang • Recruiting • Researchers: • actively looking for candidates • Ph.D. or graduating Ph.D. with good research record • Research developers: • actively looking for candidates • interested in research prototyping • strong development skills • Regular Ph.D. student interns: • strong passion is required! • look for students who have good chance to be hired by MSR when they graduate.

Outlines • Preamble • A little marketing about our research group • Two browser security projects that I am working on • Browser visual spoofing (with Jose Meseguer, Ralf Sasse, Helen J. Wang and Yi-Min Wang) • To appear in IEEE Symposium on Security and Privacy 2007 • Cross domain security violation (a brief introduction) • Conclusion: Browser/web security research is exciting

Visual Spoofing: A Serious Security Problem • A simple equation 1000 miles × trusted + 20 inches × untrusted = untrusted • Examples: status bar spoofing and address bar spoofing • IE, Firefox and Netscape all have security flaws in GUI. 20 inches, Untrusted Web server 1000 miles, trusted

Research motivation • GUI behaviors are driven by complex logic • E.g., how to handle mouse messages and update the status bar, how to update the address bar during navigations • What are the GUI states that are “spoofing states”? • Need formal definitions. • Goal: to develop a systematic approach to • Check the GUI logic against the definitions of spoofing states • Using the Maude rewriting engine as the reasoning tool • Uncover GUI logic flaws that can cause spoofing.

Overview of Our Approach Real spoofing scenarios Source code of browser GUI Visual invariant (b) Real world Formal world (a) Program Logic (pseudo code) (d) (f) User’s action sequence violation Potential spoofing scenarios Program invariant (e) (c) Execution context System state The modeled system Reasoning Engine

Case study: status bar spoofing: basic concepts Document Object Tree (DOM Tree) <html> <head><title>Page</title></head> <body> <a href="http://paypal.com"> <img src="a.jpg"> </a> <button> My button </button> </body> </html> <html> <body> <head> <a> <button> <title> <img> Page layout Element stacks Toward the user <button> <img> <img> <button> <body> <a> <button> <a> <body> status bar

Case Study: status bar spoofing: mouse handling logic • In status bar spoofing, only three raw mouse messages are relevant • MouseMove, LeftButtonDown, LeftButtonUp • Each HTML element has three virtual methods • HandleMessage, DoClick, ClickAction • Pseudo code in the paper • Every element has different behavior about updating the status bar (SetStatusText) and navigating to the target URL (FollowHyperlink). • Message bubbling (passing the mouse message to the parent element) • Every element can decide whether to continue the bubbling or cancel the bubbling • We used Maude to model the source code of the mouse handling logic

Case Study: status bar spoofing: finding attacks • System state: status bar URL, user memorized URL • User action sequence: MouseMove, MouseMove, Inspection, LeftButtonDown, LeftButtonUp (only need two MouseMoves because status bar is memoryless, a sequence of MouseMoves is equivalent to one MouseMove) (canonicalized) • Execution context: DOM tree structures (canonicalized) (at most two branches, corresponding to two MouseMoves) • Program invariant: at the time of the function call FollowHyperlink(targetURL), targetURL = user memorized URL • Use Maude to search for spoofing scenarios

Examples of Status Bar Spoofs Element stack Element layouts Element stack Element layouts • All because of unexpected combinations of element behaviors input field image paypal.com paypal.com button anchor form form form target = foo.com image target = paypal.com form target = foo.com anchor target = paypal.com img label label anchor img’s target = paypal.com label’s target = foo.com label’s target = foo.com anchor’s target = paypal.com

Case Study: address bar spoofing: basic concepts(browser, renderer, frame, markup) Browser Current Markup http://MySite.com Renderer . PrimaryFrame from MySite.com Pending Markup Frame1 from PayPal Frame2 from MSN

Case Study: Address Bar Spoofing • Program invariant: The address bar should display the URL of the current markup of the primary frame. • User action sequence: Page loading, history traveling and window opening • Execution context: A set of Boolean conditions affecting the execution path • System state: PrimaryFrame, other frames, current markups, pending markups, address bar URL ...

Pseudo code model: loading a new page Posting an event SetAddressBar Calling a function Invoking a handler Frame::SwitchMarkup NavigationComplete FollowHyperlink Markup::SetInteractive View::RenderView View::EnsureView PostParser Eventqueue start navigation ready ensure onPaint

Pseudo code model: history travel Posting an event SetAddressBar Calling a function Invoking a handler Frame::SwitchMarkup NavigationComplete LoadHistory View::RenderView Markup::SetInteractive Travel View::EnsureView PostParser History_Back Eventqueue start navigation ready ensure onPaint

Pseudo code model: opening a page in a new window InitDocHost LoadFromInfo SwitchMarkup CreateMarkup SetClientSite LoadFromInfo InitNew SetAddressBar Load View::RenderView CreatePendingDocObject LoadDocument PostParser FollowHyperlink download-content Eventqueue start-loading onPaint

Discovered Address Bar Spoof (An Atomicity Bug) Evil.com https://evil.com#xxxxx...xxxxxxx https://paypal.com

Discovered address bar spoof (a race condition) Load a new page History back https://Evil https://paypal.com https://evil c:\windows\system32\shdoclc.dl l?http

Summary of the GUI logic project • Found many new scenarios for the status bar spoofing, filed them as 9 bugs against IE. • All fixed before IE7 RC 1 (release candidate 1). • 4 new scenarios of the address bar spoofing • Non-atomic update of the address bar (2 bugs) • Non-atomic update of the content area • Race condition: multiple frames compete to be the primary • IE team has fixed two, and proposed the fixes for the other 2 to go into the next version.

Browser cross-domain attacks • Browsers need to implement isolation mechanism to make sure that scripts from http://a.com cannot access the DOM tree from http://b.com • Seemingly simple policy, surprisingly hard to enforce in current browser implementations • Many bugs have been found in IE, Firefox, Opera, Netscape • Serious consequences: • As long as you visit a malicious site, the script can steal your personal information in your hotmail, payroll, bank pages, and/or actively transfer your money. • See some demos on Windows XP • Due to async navigation, aliasing, user event semantics, interactions with non-browser components, … • Very difficult for developers to anticipate all these scenarios.

The proposed idea: script accenting • The basic idea is analogous to the accent in human languages • The accent is essentially an identifier of a person’s origin that is carried in communications • We slightly modified a few functions at the interface of the script engine and the HTML engine so that • each domain is associated with a random “accent key”, • scripts and DOM object names are in their accented forms at the interface. • A nice security property • Without needing an explicit check for the domains, the accenting mechanism naturally implies that two frames cannot communicate/interfere if they have different accent keys.

Evaluations of the script accenting mechanism • Prototyped on IE • Protection effectiveness • All cross-domain attacks that we reproduced are defeated • Transparency • Tested on many complex web applications • Virtual earth, Google map, Hotmail, Citi bank, CNN.com, Slashdot, YouOS.com, etc • Completely transparent to existing IE functionalities • Performance • Near zero performance overhead in real browsing experiences

Conclusion: browser/web security research is exciting • The territory is new, real and big. • Script, AJAX, blog, search engine, web OS, … • Attacks: phishing, spamming, click fraud, cross-site scripting, cross-domain attack, … • The threats are not well understood • Opportunity to do great analysis work • The browser security models are not strictly specified • Opportunity to propose clearer security models • Opportunity to examine existing security models • Browser implementations are still ad-hoc • Opportunity to apply program analysis techniques • Opportunity to invent implementation-level primitives and constructs • Many other emerging security problems for us to catch …

Browser Security: A New Research Territory