Vulnerability Development mailing list archives

Re: Exploiting any network protocol with secondary datachannelsopened from the server


From: mwegner () CS OBERLIN EDU (Mr. Pink)
Date: Sun, 19 Mar 2000 16:05:40 -0500


On Sun, 19 Mar 2000, Mikael Olsson wrote:

Blue Boar wrote:

I don't suppose Sandboxed Java Applets have any legal way to detemine
which ports are open on the machine they're running on, do they?


Something struck me as a possibility here. I don't know the first thing
about Java, but I'm wondering if the socket interface in the standard
Java libs has some similarities to standard BSD sockets.

In Java 2 (std. ed., jdk 1.3), Sun's java.net has two types of socket -
regular and server, server sockets being what you'd need for this type of
sneakery.  According to the API docs, it can throw I/O exceptions
(including binding) or security exceptions, the security exceptions
happening when a security manager is running and checkListen says that it
isn't allowed to open a server socket.  So it should depend on the sandbox
that the applet is playing in, and if we're talking about malicious web
applets, that means looking at particular browser sandboxes.  I don't know
how the sandboxes are built for the average web browser, but it would be
foolish (to say the least) to build a sandbox that will run unknown code
and allow it to create serverSockets without making sure it's okay, first.
Netscape, at least, doesn't let downloaded applets do anything too fun
without the Capabilities API, which means signed applets.  So a signed
applet could do malicious things under netscape, but then we're talking
about the validity of signing, rather than trusting applets.  However, one
of the things I noticed just now in a document describing signed applets
(http://developer.netscape.com/docs/technote/index.html?content=security/sectn3.html)
was that signed applets can lower a reverse lookup restriction in order to
bypass proxies when trying to "phone home". This implies that applets
can, at the very least, do some sort of communication back to the server
of their origin.  How much that can be played with is something to look
into, but if the intended victim is already pointing a web browser at the
malicious server, then there is already an opportunity to exploit a
connection through their firewall.

Mathias

Hi! I'm a .signature virus! Copy me into your ~/.signature to help me
spread!


Current thread: