[1601] in WWW Security List Archive
Re: Java "security holes'
daemon@ATHENA.MIT.EDU (Dana Hudes)
Mon Mar 11 01:51:23 1996
Date: Sun, 10 Mar 1996 22:25:21 -0500 (EST)
From: Dana Hudes <dhudes@panix.com>
To: EKR <ekr@terisa.com>
cc: www-security@ns2.rutgers.edu
In-Reply-To: <199603100415.UAA01289@itech.terisa.com>
Errors-To: owner-www-security@ns2.rutgers.edu
I realize the potential security holes involved but malicious
use is succeeding when we can no longer accomplish legitimate use.
It is perfectly reasonable to warn that connection to third party is
being requested and ask for explicit approval, just as Netscape does when
the public key certificate is funky in some way (I have this all the time
with PAWWS , pawws.secapl.com, displaying my portfolio and proceeding to
request current price quotes from quotes.secapl.com; the certificate is
not intended for quotes, only pawws).
This allows the user to be warned of your proxy attack and still be able
to use the Net in a flexible manner for legitimate purposes.
I am definitely concerned over possible malicious uses but a compromise
is neccessary between forbidding everything unconditionally and allowing
everything unconditionally. This list has been holding forth for the
former, but I do not propose the latter.
Dana Hudes
Advanced Solutions Inc.
On Sat, 9 Mar 1996, EKR wrote:
> Date: Sat, 9 Mar 1996 20:15:19 -0800
> From: EKR <ekr@terisa.com>
> To: dhudes@panix.com
> Subject: Re: Java "security holes'
>
> >Restricting outgoing connections (or incoming!) to the server you got the
> >applet from is a heavy restriction of utility to the legitimate applets.
> >You prohibit two stations on the net from talking, you eliminate data
> >sharing between peers. One cannot have a multiplayer game. One cannot
> >contact a certificate server . One cannot access a database server that
> >is different from the web server.
> You've got to think through the security implications of not doing
> this. Consider the case where you have some machine behind a firewall,
> and this machine is running a Java applet. Most firewalls allow
> some communication with the outside world. For example, suppose
> it allows a telnet proxy (to telnet out). The applet telnets to
> the attacking machine and simultaneously opens a TCP connection to
> some internal machine and then proxies all the data that the
> attacking machine sends to the internal machine. Bingo: instant
> nullification of firewall.
>
> The same approach can be used with say an HTTP proxy, though you
> have to spend a little bit of energy coding TCP data into HTTP.
>
> In short, these are serious security problems.
> -Ekr
>
>
>
>
