Bugtraq mailing list archives
Another way to exploit local classes in Java
From: andre () CS UCSB EDU (Andre L. Dos Santos)
Date: Wed, 8 Oct 1997 16:34:20 -0700
The attack described here is of interest because it uses the CLASSPATH feature, which has been known to allow security breaches. However, it uses it in a different way. The result is that the security enhancements that have been introduced by Netscape to fix the previously known vulnerability using this feature are ineffective in stopping this attack. The danger of setting the CLASSPATH environment variable to a path where malicious classes are located is well known. Because of this Netscape began restricting what a class loaded from the local disk can do starting with Navigator 2.x. In Navigator 3.x Netscape took it one step further with its setScopePermission model, and Communicator 4.x has signed applets, where a capability based model is enforced. Microsoft has not enhanced the model suggested by Javasoft. The security model implemented by Netscape and Microsoft considers any local class as a "system" class. Therefore, when a class is needed the browser searches the local disk before requesting a class from the net. Thus, if the user has classes in his/her local disk that have the same name as classes that are used by a site, these classes will be used instead of the ones from the network. Because of this it is possible to implement an attack on a user interacting with a target site, where classes on the local disk implement the functionality desired by the attacker. Our attack is able to proceed because the classes that are used in our attack do not need to request or require special privileges. The attack uses only the privileges granted to classes loaded using the classloader. In order to understand the risks of this flaw we have implemented a demo of the attack on the Reliable Software Group site. This demo has as a target the site of a bank that uses Java for login. The results of this demo is that although the bank site uses SSL, a user is able to verify that he/she is interacting with the desired site, when being attacked. So there is no indication of an attack, and the user can verify the bank's certificate. However, in the demo, instead of the browser sending the login information to the bank server, it sends it to our server, in plain text. As is the case with most of the previously reported CLASSPATH attacks, for our attack it is necessary for the user to load classes on the CLASSPATH. One can not stress enough that there is a lot of trust involved with downloading files onto your computer and pre-loading classes onto your classpath. Therefore, if the user is following the procedure of installing only files that he/she can be 100% sure will not do any harm, then this CLASSPATH attack will not work. We believe, however, that it is likely that one could trick a user into loading .zip files. One such file could have the classes necessary for the attack in addition to a set of useful and harmless classes. We have notified Netscape and Microsoft about our attack. Microsoft answered that this is the way that Java is supposed to work. Netscape said that this problem can be partially solved using the function matchPrincipal from their enhanced model. They also added that they are working on improvements for this model and will consider a total solution to the problem. Andre Santos Reliable Software Group UCSB
Current thread:
- SNMP Insecurity, (continued)
- SNMP Insecurity Aleph One (Oct 08)
- Malicious Linux modules Runar Jensen (Oct 08)
- Re: L0pht Advisory: IMAP4rev1 imapd server Casper Dik (Oct 09)
- Security flaw in PGPverify of INN Lutz Donnerhacke (Oct 09)
- Re: L0pht Advisory: IMAP4rev1 imapd server Kragen Sitaker (Oct 09)
- Security flaw in Count.cgi (wwwcount) Razvan Dragomirescu (Oct 10)
- Huge security holes in Microsoft FP98 server extensions for Apache Marc Slemko (Oct 11)
- Re: Huge security holes in Microsoft FP98 server extensions for Aleph One (Oct 11)
- DOS PC FTP SERVER Efrain Torres Mejia (Oct 11)
- _very_ poor ISN generation on Ascend MAX (fwd) Marc Slemko (Oct 11)
- Another way to exploit local classes in Java Andre L. Dos Santos (Oct 08)
- Re: Possible weakness in LPD protocol Oliver Friedrichs (Oct 03)
- Re: Possible weakness in LPD protocol Eivind Eklund (Oct 03)
- Re: Possible weakness in LPD protocol Doug Hughes (Oct 05)