[9500] in bugtraq
Re: open socket in java
daemon@ATHENA.MIT.EDU (Posick, Steve)
Fri Feb 12 12:00:50 1999
Date: Tue, 9 Feb 1999 18:47:44 -0500
Reply-To: "Posick, Steve" <posicks@ESPN.COM>
From: "Posick, Steve" <posicks@ESPN.COM>
To: BUGTRAQ@NETSPACE.ORG
I've written an applet that exploits this flaw. I could NOT get the
applet to open a socket to any host other
than the host that the applet resides on. I could connect to the
applet from any other machine, but the applet
was unable to accept the connection using the ServerSocket.accept()
method. Therefore to my knowledge
this bug can not be used by itself to transfer data to any host other
than the HTTP server in which it resides.
-----Original Message-----
From: Tim Wright [SMTP:wright@QUCIS.QUEENSU.CA]
Sent: Tuesday, February 09, 1999 9:55 AM
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: open socket in java
On Fri, 5 Feb 1999, Lincoln Stein wrote:
> The main issue, I think, is information leakage between the Web
site
> that uses the applet and the applet's author. Consider this
scenario:
> a Bad Guy puts out a compiled applet in the public domain that
seems
> to do something innocent like chart business graphics. Some company
> then picks up this applet and uses it to display its confidential
> business plan to authorized hosts in branch offices. Unbenknownst
to
> the company or the branch office, the applet has actually opened a
> listen socket, has accepted a connection from the applet's original
> author, and is currently transmitting the confidential information
to
> an untrusted host!
the missing information here that this scenario doesn't contain, is
that
the applet's original author must know the host that the applet is
running
on, in order to connect to the applet.
This information can be easily sent by the applet to the bad guy by
making
a http request - hiding information in the URL. We implemented this
type
of communication, allowing a java applet to communicate with an
arbitary
server (needed access to files on a different machine than the HTTP
server)
however, all the confidential data can be sent in this manner.
A more pertinent problem is that Java can dynamically load classes
through
a socket. The new code might exploit a security hole which was unknown
at
the time the applet was written - a company might assume that because
an
applet was written _before_ a security hole was found, it cannot
exploit
this hole, and therefore the company doesn't need to fix the hole. (i
know, bad logic, but ...?)
Tim
http://stl.qucis.queensu.ca/~wright
When in doubt, doubt. It's what set's us apart from the animals.
(If you define animals as Politicians and Technocrats)
