4/11/2007 and 4/12/2007 Purdue University and University of Illinois at Urbana-Champaign Browser Security: A New Research Territory Shuo Chen Cybersecurity

4/11/2007 and 4/12/2007 Purdue University and University of Illinois at Urbana-Champaign

Browser Security: A New Research Territory

Shuo ChenCybersecurity and Systems Management Group

Microsoft Research, Redmond, WA

4/11/2007 and 4/12/2007 Purdue University and University of Illinois at Urbana-Champaign Slide: 2

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



Cybersecurity and Systems Management Grouphttp://research.microsoft.com/csm/

Current security projectsHoneyMonkey: client-side honeypots to find malicious websitesSearchRanger: finding spam websites that try to promote junk pages into top positions in search engines.Browser security (this talk)

Current systems management projectsFDR (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 WangRecruiting

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




To appear in IEEE Symposium on Security and Privacy 2007




Visual Spoofing: A Serious Security Problem

A simple equation 1000 miles × trusted + 20 inches × untrusted = untrusted

Examples: status bar spoofing and address bar spoofingIE, Firefox and Netscape all have security flaws in GUI.

1000 miles, trusted

Web server 20 inches, Untrusted


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

Execution context

Execution context

System stateSystem state

Program Logic (pseudo code)

The modeled system

User’s action sequence

User’s action sequence

Programinvariant

Reasoning Engine

Visualinvariant

Source code of browser GUI

Source code of browser GUI

viol

atio

n

Potential spoofing scenarios

Potential spoofing scenarios

Real spoofing scenarios

Real spoofing scenarios

Real world

Formal world

(d)

(e)

(c)

(a)

(b)

(f)


Case study: status bar spoofing: basic concepts

<body><button>

status bar

<html>

<head>

<title>

<body>

<a>

<img>

<button>

<button><img>

<a>

<html> <head><title>Page</title></head> <body> <a href="http://paypal.com"> <img src="a.jpg"> </a> <button> My button </button> </body></html>

<body><a>

<img><button>

Toward the user

Document Object Tree (DOM Tree)

Page layout

Element stacks


Case Study: status bar spoofing: mouse handling logic

In status bar spoofing, only three raw mouse messages are relevantMouseMove, LeftButtonDown, LeftButtonUp

Each HTML element has three virtual methodsHandleMessage, DoClick, ClickActionPseudo 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

All because of unexpected combinations of element behaviors

input field

anchor

form

paypal.com

form target = foo.comanchor target = paypal.com

image

button

form

paypal.com

form target = foo.comimage target = paypal.com

Element stack Element layouts Element stack Element layouts

label

anchor

label’s target = foo.comanchor’s target = paypal.com

img

label

img’s target = paypal.comlabel’s target = foo.com


Case Study: address bar spoofing: basic concepts(browser, renderer, frame, markup)

Renderer

Frame1 from PayPal

Browser

.http://MySite.com

Current Markup

Pending Markup

PrimaryFrame from MySite.com

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

FollowHyperlink

startnavigation

ready

PostParser

Eve

ntqu

eue

Markup::SetInteractive

NavigationComplete

SetAddressBar

Frame::SwitchMarkup

onPaint

View::EnsureView

View::RenderView

Posting an event

Calling a function

ensure

Invoking a handler


Pseudo code model: history travel

startnavigation

ready

PostParser

Eve

ntqu

eue

Markup::SetInteractive

NavigationComplete

SetAddressBar

Frame::SwitchMarkup

onPaint

View::EnsureView

View::RenderView

ensure

History_Back

Travel

LoadHistory

Posting an event

Calling a function

Invoking a handler


Pseudo code model: opening a page in a new window

CreatePendingDocObject

start-loading

LoadDocument

Eve

ntqu

eue

Load

CreateMarkup

SetAddressBar

LoadFromInfo

LoadFromInfo

FollowHyperlink

onPaint

PostParser

View::RenderView

download-content

InitNewSetClientSite

InitDocHostSwitchMarkup


Discovered Address Bar Spoof (An Atomicity Bug)

https://evil.com#xxxxx...xxxxxxxhttps://paypal.com


Discovered address bar spoof (a race condition)

https://evil https://paypal.comc:\windows\system32\shdoclc.dl l?http

History back Load a new page


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 areaRace condition: multiple frames compete to be the primaryIE team has fixed two, and proposed the fixes for the other 2 to go into the next version.


Outlines

Preamble







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 XPDue 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 languagesThe 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 propertyWithout 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 effectivenessAll cross-domain attacks that we reproduced are defeated

TransparencyTested on many complex web applications

Virtual earth, Google map, Hotmail, Citi bank, CNN.com, Slashdot, YouOS.com, etc

Completely transparent to existing IE functionalities

PerformanceNear zero performance overhead in real browsing experiences


Outlines

Preamble







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 understoodOpportunity to do great analysis work

The browser security models are not strictly specifiedOpportunity to propose clearer security modelsOpportunity to examine existing security models

Browser implementations are still ad-hocOpportunity to apply program analysis techniquesOpportunity to invent implementation-level primitives and constructs

Many other emerging security problems for us to catch …

Documents

4/11/2007 and 4/12/2007 Purdue University and University of Illinois at Urbana-Champaign Browser Security: A New Research Territory Shuo Chen Cybersecurity