Download
a systematic approach to uncover security flaws in gui logic n.
Skip this Video
Loading SlideShow in 5 Seconds..
A Systematic Approach to Uncover Security Flaws in GUI Logic PowerPoint Presentation
Download Presentation
A Systematic Approach to Uncover Security Flaws in GUI Logic

A Systematic Approach to Uncover Security Flaws in GUI Logic

101 Vues Download Presentation
Télécharger la présentation

A Systematic Approach to Uncover Security Flaws in GUI Logic

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. A Systematic Approach to Uncover Security Flaws in GUI Logic Shuo Chen†, José Meseguer‡, Ralf Sasse† ‡, Helen J. Wang†, Yi-Min Wang† † Systems and Networking Group Microsoft Research ‡ Dept. of Computer Science University of Illinois at Urbana-Champaign

  2. 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

  3. Research motivation and goal • 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 • Need a systematic approach to examine its correctness • Goal: to apply formal methods to reason about GUI logic in order to proactively uncover browser spoofing bugs.

  4. 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 (The Maude System: a rewriting logic engine)

  5. 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

  6. 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

  7. 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

  8. 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 image label label anchor img’s target = paypal.com label’s target = foo.com label’s target = foo.com anchor’s target = paypal.com

  9. 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

  10. 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 ...

  11. 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

  12. 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

  13. 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

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

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

  16. Summary of bug reporting for IE 7 • 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.

  17. Conclusions • Formulated GUI logic correctness as a new research problem • Proposed a systematic approach to proactively uncover security flaws in browser GUI • Demonstrated the benefit of the systematic approach to the GUI implementation. • The approach is not IE specific. • Other browsers (e.g., Firefox, Opera, Netscape, etc) • Non-browser applications (e.g., Outlook, Outlook Express)

  18. Discussions • Are there spoofing bugs that are not logic flaws? • Picture-in-picture, pop-up covering, chromeless window, symbol similarities (“vv” vs.“w”, “l” vs. “|”, etc) • Should we rely on users’ security awareness for anti-phishing? • Ideally, no. An ideal security infrastructure should be transparent! • Many users ignore security warnings. [Dhamija-CHI-06][Wu-CHI-06][Schechter-S&P-07] • In reality, people have not found a satisfactory way for transparent security • White-listing? Sacrifice the openness of the web. Does not scale. • Black-listing or intrusion detection? The signature precision and timeliness • Anti-phishing will remain a joint effort between browser vendors and users for many years • IE 7 has made many the efforts to make the GUI authentic. • “Seat belts” are effective only when you “buckle up”! (Not ideal, but … )