Interesting People mailing list archives
IP: two detailed notes on java(script) security
From: Dave Farber <farber () central cis upenn edu>
Date: Fri, 23 Feb 1996 19:15:34 -0500
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.
Current thread:
- IP: two detailed notes on java(script) security Dave Farber (Feb 23)