IP: two detailed notes on java(script) security

[Dave Farber <farber () central cis upenn edu>]

Date: Fri, 23 Feb 96 10:03:49 -0500
From: John Robert LoVerso <loverso () osf org>
Subject: Netscape Navigator 2.0 exposes user's browsing history


While riding home this past Wednesday (on my accident free commuter-rail
line), I came up with an approach to utilize the JavaScript "feature" of
Netscape 2.0 to track a user's browsing actions.  The tracking happens in
real time with the user's browser dutifully sending results back to a remote
server, starting from the time the user visits a page with the devious
JavaScript embedded in it.  It can thus sniff any passwords or keys the user
might use in a URL.


My example version runs in a browser window that the user can see.  I'm only
demonstrating the vulnerability.  Practically, the window can be made so
small as to be invisible to the casual user.  It also helps that a user
isn't even informed when the HTML page they just loaded has some JavaScript
code within it.


Think about Netscape's new JavaScript-laden home page.  The default action
on startup of Netscape 2.0 is to go to that page.  It could easily start off
tracking your browsing actions.  With the new on-line frontier being driven
by advertising, the value of such a log is immense.  Of course, if Netscape
really wanted to do something like this, they could embed all sorts of
things directly in their browser.  Naturally they don't, but this is
something that people often clamor about (e.g., the recent Microsoft Word
and the never ending AOL controversies).


As it stands, with Netscape 2.0 you cannot disable JavaScript.  You can
disable Java.  This is an interesting choice on their part, since at least
there has been a significant effort on the part of many people to justify
Java's claim of security and safeness.  Thousands of people have pored over
the code and specifications.


But, JavaScript and Java are totally different things.  They share common
names and syntax, but they don't share implementations.  One is a byte
compiled language executing in a restrictive state machine, the other is an
interpreted scripting languages with vastly different properties.  Compared
with the thousands of people have looked at the source to Java, no one has
seen JavaScript.  Its specifications are defined by the implementation,
which to date is solely Netscape 2.0.  We're told it is "Secure. Cannot
write to hard disk", which is how Java is also described.  Is there enough
commonality for such a comparison?  It is hard to determine that a program
is safe or secure after studying it.  It is impossible without.


My particular history tracker is the third (or fourth?) way to steal private
data from a user via JavaScript.  It stands out as the first one that does
it in real time, reporting history as the user is browsing.  In an
interesting bit of irony, as I was writing the code to exploit this hole, a
news article from someone at Netscape appeared noting how they has fixed 2.0
during the "beta-test" period to avoid the latest of the history stealing
approaches.


As it stands, JavaScript adds a viral element to HTML.  I'm not sure why
Netscape doesn't ship JavaScript disabled by default or why they don't alarm
the user before it starts to execute, or opens up new windows.


Finally, it is interesting to note that the Netscape Navigator already has
the building blocks to block the execution of any JavaScript (or Java) code
that doesn't come digitally signed from some trusted source.  This would
help provide a real safeguard against the types of attack downloaded code
opens up.


My JavaScript examples are at http://www.osf.org/~loverso/javascript/.


John Robert LoVerso  OSF Research Institute


  Added note:
    Did you ever try to teach someone the importance of keeping
    their ATM PIN secret, only to find that they never lock the
    doors to their house?
    A non-empty subset of the hosts who have visited my JavaScript
    "tracker" page run an X server with no access control enabled.


------------------------------


Date: Wed, 21 Feb 1996 20:40:10 -0800
From: Marianne.Mueller () Eng Sun COM (Marianne Mueller)
Subject: Re: Java security (Dean, RISKS-17.77)


This message is a response to the DNS spoofing attack described in Drew
Dean's IEEE Security and Privacy paper, referred to by Drew Dean in his
RISKS-17.77 posting as being in http://www.cs.princeton.edu/~ddean/java/ .


Background


A bit of background on DNS: (apologies for the oversimplification)


DNS is the internet "Domain Name Service".  It provides the mapping between
computer names and computer addresses.  For example, the name
ds.internic.net has the 3 IP addresses, 198.49.45.10, 192.20.239.132, and
204.179.186.65.  Probably, each IP address eventually is mapped onto a
different computer, although multiple IP addresses could also map onto a
single computer.  The reason for many-to-many name-to-address mappings is
that it enables system administrators to balance the network load on their
machines.  The name ds.internic.net is probably accessed hundreds of
thousands of times every day by people all over the network, so it makes
sense for that one name to be served by multiple machines with multiple IP
addresses.


Let's use the term "DNS spoofing" to mean that a computer on the
internet has been able to advertise a false IP address for itself.
DNS spoofing isn't directly related to Java, but might be used as part
of a Java attack applet.


Attack


The attack scenario is like so.


1) The machine evil.hacker.com advertises two IP addresses for
itself, the real IP address for that machine (say 1.1.1.1) and a fake
IP address for that machine (say 6.6.6.6).  The fake IP address is
actually the address of target.com, which is the computer the attack
applet wants to try to connect to, later on.


2) Someone using a Java-powered browser loads an applet from
evil.hacker.com.  Now, applets are allowed to make network connections
only to the machine they came from, which in this case is
evil.hacker.com.  However, this attack applet tries to open a
connection to the computer named "target.com".


3) The applet security manager does a DNS lookup on the name
target.com, and checks if its IP address is in the pool of IP
addresses that this applet is allowed to connect to.  It gets the
address 6.6.6.6.  It turns out that this is one of the two addresses
associated with evil.hacker.com, and so the connection is allowed.
The connection should not be allowed.


Why is this attack possible?


There are two reasons why this DNS Spoofing attack works:


        1)  It's relatively easy for someone to advertise false IP
            addresses.   That is, it's relatively easy for someone
            to run their own domain name resolver.


        2) The applet security manager allows an applet to connect
           to any of the IP addresses associated with the name
           of the computer that it came from.


What's the fix?


The right solution for this problem is to make the Domain Name Service
more secure.  It shouldn't be so easy for anyone to advertise false
names or false addresses.


A fix for the applet security manager is to be more strict about deciding
which computers an applet is allowed to connect to.  The Java system needs
to take note of the actual IP address that the applet truly came from
(getting that numerical address from the applet's packets, as the applet is
being loaded), and thereafter only allow the applet to connect to that exact
same numerical address.  Additionally, the Java system could be even
stricter than that, by declaring that an applet can only connect to the same
port number that it came from, in addition to only being allowed to connect
to the same IP address that it came from.


What's the bottom line for me today?


An applet on its own cannot carry out this attack.  It would have to be
working in conjunction with a hacked DNS server owned and ascribed to some
domain.


Also, the attack applet would have to know the name and IP address of
machines inside a corporate firewall, in order to try to establish a
connection to machines behind the firewall.


Sun will be distributing a patch to the applet security manager to implement
the more rigorous checking described above.  That fix will be available
within a few days, and it will be distributed in source code and in bytecode
format.