Please send cash

I just picked this up from the Risks forum:

> Date: Mon, 30 Oct 1995 16:14:59 -0500
> From: Drew Dean <ddean@CS.Princeton.EDU>
> Subject: HotJava 1.0 alpha 3 security issues
> 
> We have found several security problems in the 1.0 alpha 3 release of
> HotJava from Sun Microsystems.  The two most important problems are that
> HotJava does not enforce the stated limits on where an applet can connect to
> (an applet can talk to any place with which you have IP-level connectivity),
> and HotJava is vulnerable to a man-in-the-middle attack, where someone can
> watch your web-surfing, both seeing your requests, and the content that you
> receive.

Two of the Java attacks I outlined in this forum and got abuse for.

> While HotJava prevents applets from actively opening connections that
> violate the user-selected security policy, it allows an applet to accept
> connections from anywhere.  At this point, an applet only has to use any one
> of a number of channels to communicate where it is, and have the remote end
> do the active open.
> 
> HotJava also allows an applet to set the proxy servers that the browser
> uses.  This opens up a huge hole for anyone concerned about the privacy of
> their web surfing.

Attacks 31-49 work here.

> Please note that these bugs are specific to the 1.0 alpha 3 release, and are
> _not_ bugs in the Java language itself, nor do they apply to Netscape 2.0
> beta 1J, which doesn't permit network connections.  We have notified Sun of
> these problems, and are presently writing a paper on these and other issues.
> We will make more information available on our Web page after we hear back
> from Sun.

Drat - Sun doesn't offer awards.

> 
>     http://www.cs.princeton.edu/~ddean/java/
> 
> Drew Dean				Dan Wallach
> ddean@cs.princeton.edu			dwallach@cs.princeton.edu

Inquiring minds want to know.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

> While HotJava prevents applets from actively opening connections that
> violate the user-selected security policy, it allows an applet to accept
> connections from anywhere.  At this point, an applet only has to use any one
> of a number of channels to communicate where it is, and have the remote end
> do the active open.

What if I start a Java applet then send it a faked TCP/IP packet from another 
host? Can I hotwire an outgoing connection that appears to be from the victim 
host?

TCP/IP connections are not really all that directed. It is only the startup 
phase that is trully directed - someone has to start a conversation.

Planned sequence of events :

Mallet:
	Send out Java applet to Alice
	Send Bob a connection request packet on port 22
	Alice's Java applet is accepting connections.
	Send Alice a "request" packet claiming to come from port 22
	Should now have an outgoing connection.

???? I'm not a TCP/IP hacker (much). I'll ask our guru tommorow after we
are done with the NSA.


		Phill

> > While HotJava prevents applets from actively opening connections that
> > violate the user-selected security policy, it allows an applet to accept
> > connections from anywhere.  At this point, an applet only has to use any one
> > of a number of channels to communicate where it is, and have the remote end
> > do the active open.
> 
> What if I start a Java applet then send it a faked TCP/IP packet from another 
> host? Can I hotwire an outgoing connection that appears to be from the victim 
> host?

I think so.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236