New Challenges of Security Verification in Browser Development

1. New Challenges of Security Verification in Browser Development Shuo Chen ISRC, MSR March 2008

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

3. Browser Logic Bugs are Everywhere • 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. Understanding the challenges • 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. Understanding the challenges (cont.) Complexity! • 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. Case Studies of Browser Logic Bugs Even seemingly simple policies are difficult to securely enforce, due to logic complexity.

7. GUI Logic Bugs

8. https://evil.com Address bar spoof 1 (due to aborted navigation) • Navigation is not transactional. Can be aborted in unsafe states. (Fixed in February 2008) Navigate to • https://eval.com/ https://evil.com 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!"); The frame is ready for https://evil.com/ Arbitrary contents written to the frame

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

10. Our recent workPretty-Bad-Proxy:An Overlooked Adversary in HTTPS Deployments

11. About End-to-End Crypto Protocols • 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. PBP adversary browser PBP (the bad guy) server HTML Engine (browser security model) SSL SSL Encrypted traffic TCP/IP TCP/IP TCP/IP Faked data Unencrypted traffic, accessible by PBP

13. Discovered Vulnerabilities • 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. Example: Vulnerability #1 • Proxy’s error pages are rendered in the context of the target server. browser PBP server <iframesrc= “https://paystub”> https://paystub Server not found https://paystub

15. Bad-enough situation • 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. Really-bad situation: "auto-detecting proxies" capability • 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. PBP project status • 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. Potential Approaches toDeal with Browser Logic Bugs

19. It's all about dealing with logic complexity • 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. Potential approaches to address the chanllenges • (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. Formal Methods to Uncover Logic Flaws in Browser GUI (in IEEE S&P'07) • 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. "Script Accenting" to Defeat Cross-domain attacks (in ACM CCS'07) • 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. Summary

24. Summary • 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. New Oppotunities • 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. Acknowledgements • 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)