Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Shuo Chen ISRC, MSR March 2008. 2 Browser security is still very broad. I usually differentiate three types of issues – their causes and potential solutions.

Similar presentations


Presentation on theme: "1 Shuo Chen ISRC, MSR March 2008. 2 Browser security is still very broad. I usually differentiate three types of issues – their causes and potential solutions."— Presentation transcript:

1 1 Shuo Chen ISRC, MSR March 2008

2 2 Browser security is still very broad. I usually differentiate three types of issues – their causes and potential solutions are different. Browser security issues Logic bugs Usability and understandability issues Over-permissive high-level policies

3 3 Logic bugs exist at every layer in the browser architecture. (Everything you depend on is buggy) GUI layer E.g., logic bugs may result in visual spoofing HTML and Jscript layer E.g., cross-domain access due to logic bugs in the domain isolation mechanism Communication layer: E.g., Logic bugs that allow any device that can sniff browser traffic to break the protection of HTTPS. (Our recent work “pretty-bad-proxy”)

4 4 The violated security policies are fairly basic and look simple, e.g., The address bar URL should be the URL of the top level document; When mouseover a static hyperlink, the status bar should display the target URL; A script in a.com context cannot access a document in b.com context However, an important lesson I learned in browser security research is: Implementing correct logic to achieve even the most basic security requirements in browsers is challenging The challenges are likely to be understated if we haven’t carefully studied these bugs.

5 5 Why logic correctness is challenging in browsers? A commodity browser is so complex that no human brain power can verify its correctness with high confidence. Most are tricky bugs. Very few “stupid” ones.

6 6 Even seemingly simple policies are difficult to securely enforce, due to logic complexity.

7 7

8 8 https://paypal.com w1=open("https://paypal.com/"); s1 = a string containing unprintable characters; w1.location="https://eval.com/"+s1; w1.document.write("arbitrary contents!"); Navigate to https://eval.com/  The frame is ready for https://evil.com/  Arbitrary contents written to the frame Navigation is not transactional. Can be aborted in unsafe states. (Fixed in February 2008) https://evil.com

9 9 https://paypal.com c:\windows\system32\shdoclc.dl l?http History back Load a new page Two frames competing. 50:50 chance to go out-of- sync with the address bar. Fixed in before IE 7 was shipped

10 10

11 11 Cryptographic protocols: designed to provide secure communications over insecure networks. E.g, HTTPS Our curiosity: is the same adversary model rigorously considered when people deploy the protocols in browser/web systems. We assume the Pretty-Bad-Proxy adversary model It is an HTTP proxy that completely controls unencrypted traffic, but cannot break the cryptography between the browser and the server.

12 12 HTML Engine (browser security model) SSL TCP/IP browser PBP (the bad guy) server Encrypted traffic Unencrypted traffic, accessible by PBP Faked data

13 13 We found that a PBP can compromise HTTPS- deployed applications in many ways Proxy’s malicious error responses Proxy redirecting javascript requests Proxy loading HTTP javascript into HTTPS context Proxy making the browser to display cached certificate with bogus page contents. Proxy stealing HTTPS session cookies using HTTP requests.

14 14 <iframe src= “https://paystub”> Proxy’s error pages are rendered in the context of the target server. browser PBP server https://paystub Server not found https://paystub

15 15 When you stay in a hotel or in an Internet café When you connect to a free wireless access point on a bus. When you use a third-party free anonymizer (an HTTP proxy) When the proxy of the corpnet is hacked by an insider or accidentally infected by a virus. Don’t trust HTTPS in these scenarios, although HTTPS is supposed to protect you against untrusted proxies.

16 16 It is turned on by default. You don’t have to connect to an untrusted proxy intentionally. Attackers can do that for you easily. Wireless access point (unencrypted or WEP) Sniffing on Ethernet. A device that can sniff the traffic can break HTTPS communications. No security at all.

17 17 Microsoft has notified other affected browser vendors (Firefox, Opera). They acknowledged the issues. Microsoft has fixed IE bugs in IE 8 Beta 1, waiting to evaluate compatibility impact before shipping patches for down-level IEs. Opera has fixed their bugs in December 2007. Firefox acknowledged these issues and planned to fix. We are waiting for the resolution of these issues in order to submit the paper.

18 18

19 19 It is almost impossible for developers to anticipate the possibilities of security attacks, because: Tight interactions with other components, e.g., file system, XML, Flash, etc. Non-transactional: no guarantee of fail-safe. Concurrancy: possibility of race conditions Inter-page scripting is conditionally permitted. A platform rendering rich contents, e.g., HTML and Jscript. (compare to Telnet, FTP or SSH)

20 20 (1) Formal reasoning If the code logic can be modeled and the high-level security specification can be formally defined, we can use formal methods to explore the logic combinations to prove or disprove the specification. We proposed this approach to reason about IE’s GUI logic (2) Runtime enforcement of interface invariants If the internal logic of a module is too complex to model, we enforce invariants of its interfaces. We proposed this approach to defeat cross-domain attacks.

21 21 Goal: to apply formal methods to reason about GUI logic in order to proactively uncover visual spoofing bugs. Examined the status bar logic and the address bar logic. Found 13 spoofing bugs, 11 of them were fixed before IE 7 was shipped.

22 22 In human languages, accent is essentially an identifier of a person’s origin that is carried in communications Script accenting Each domain is associated with an “accent key”. Scripts and HTML object names are encoded in their accented forms at the interface between the script engine and the HTML engine. Scripts won’t be compiled and executed in a different domain because of accent mismatch.

23 23

24 24 Browser logic correctness is a critical component in web security Because of the complexity, to ensure logic correctness is challenging. Combinations of low-level behaviors violate high-level security policies. Do not understate the challenges Security policies often look fairly simple Difficult to see the challenges without in-depth investigations on real-world bugs.

25 25 New research opportunities More effort should be spent simply to understand logic bugs better Propose solutions based on the understanding. It’s fun To probe the logic and piece together your knowledge; try to do something that most people thought impossible …

26 26 Collaborators Ziqing Mao (Purdue, Security, Intern) Jose Meseguer (UIUC, formal methods) David Ross (MS, Security Tech Unit) Ralf Sasse (UIUC, formal methods, Intern) Helen J. Wang (MSR, Security) Yi-Min Wang (MSR, Internet Services) Ming Zhang (MSR, Networking)


Download ppt "1 Shuo Chen ISRC, MSR March 2008. 2 Browser security is still very broad. I usually differentiate three types of issues – their causes and potential solutions."

Similar presentations


Ads by Google