Java Security Loophole?

Java Security Loophole?

Post by Marty Ha » Sat, 03 Feb 1996 04:00:00



Java allows applets to open socket connections to the machine from

showed how this could be used to create an applet that sent you mail
(with the hostname of the client) everytime somebody accessed your
WWW page.

This raised a question about security in my mind. Here are two
possible scenarios where this could be used in a malicious
manner. Both assume Joe Cracker writes a malicious applet hosted on
www.cracker.com, and is accessed by J. Random User at
innocent.com.

(A) Joe puts an applet on his page that, when it is loaded, connects
back to the SMTP port on cracker.com and sends forged threatening mail

started from innocent.com (the first Received: entry) and they assume
that the forger simply used cracker.com's mail port (the second
Received: line) as a way to launch the attack. The system logs at
innocent.com show that it was J. Random User that made the
connection. J. Random gets arrested. OK, not arrested, but he at least
comes under suspicion.
        Nobody even considers the possibility of an applet being
involved, especially because the applet was written to only be
triggered from innocent.com, and because Joe Cracker immediately
removed it once it was triggered.

(B) Joe puts an applet on his page that, when it is loaded by a user
from innocent.com, connects to the telnet port and tries to log in as
root using random passwords. The system admin on cracker.com notices
this and contacts the sysadmin at innocent.com. Two hours later,
J. Random is called to his bosses office, where his system
administrator shows logs showing his account connected to cracker.com
and tried to get root. J. Random denies all knowledge, and his boss
has to choose whether to believe him or the system logs. J. Random
gets fired.
        Again, Joe Cracker deleted the applet as soon as it was
triggered, and nobody even thinks of this as a possibility.

Now, I am not claiming that this is a huge security hole. But perhaps
it opens the door a crack by faking cracking activity that would be
attributed to the wrong person. So my question is whether is is possible
for Java to know the port from which the applet was originally
loaded? (Since you can't assume it will be port 80). If so, are there
negative consequences to having the default behavior be to only allow
an applet to connect back to the host *and* port from which it was
loaded? This would mean that multi-player games would require the user
to set some flag or click some verification to allow additional ports,
but then the user would be warned. Or does the very remote possibility
of these sort of attacks make the restriction to the same port not
worth the bother? Or are there additional problems I haven't
considered?
                                        - Marty
(proclaim '(inline skates))

 
 
 

Java Security Loophole?

Post by David Hopwo » Sun, 04 Feb 1996 04:00:00




>Java allows applets to open socket connections to the machine from
>which the applet was loaded. [...] This raised a question about security
>in my mind. Here are two possible scenarios where this could be used in
>a malicious manner. Both assume Joe Cracker writes a malicious applet
>hosted on www.cracker.com, and is accessed by J. Random User at
>innocent.com.

>(A) Joe puts an applet on his page that, when it is loaded, connects
>back to the SMTP port on cracker.com and sends forged threatening mail

>started from innocent.com (the first Received: entry) and they assume
>that the forger simply used cracker.com's mail port (the second
>Received: line) as a way to launch the attack. The system logs at
>innocent.com show that it was J. Random User that made the
>connection.

It is no more difficult for Joe to telnet to his own SMTP port (or that of
whatever host he likes, for that matter), and forge the same thing - including
the Received: entry.

If you receive an unwelcome or forged mail, then (at least) _all_ the hosts
on the Received lines are suspects.

Quote:>(B) Joe puts an applet on his page that, when it is loaded by a user
>from innocent.com, connects to the telnet port and tries to log in as
>root using random passwords. The system admin on cracker.com notices
>this and contacts the sysadmin at innocent.com. Two hours later,
>J. Random is called to his bosses office, where his system
>administrator shows logs showing his account connected to cracker.com
>and tried to get root.

This is slightly more of a problem. Note that the sysadmin of cracker.com
could easily just pretend that an attack had happened when none in fact had,
and produce forged logs. So the difference here is that an 'ordinary user'
is able to do this.

Something slightly like this happened to a machine that I run (I was in a

being careless with their password, rather than Java). There were some other
significant differences, but my experience was that no-one was jumping to
conclusions, and all the relevant possibilities were considered (including,
briefly, me forging the logs).

Quote:>Now, I am not claiming that this is a huge security hole. But perhaps
>it opens the door a crack by faking cracking activity that would be
>attributed to the wrong person. So my question is whether is is possible
>for Java to know the port from which the applet was originally
>loaded? (Since you can't assume it is port 80).

Yes - it is determined by the protocol: for HTTP, either 80 or the number
immediately after the host name in the URL.

Quote:>If so, would there be
>negative consequences to having the default behavior be to only allow
>an applet to connect back to the host *and* port from which it was
>loaded?

This is only really useful for things like http POST requests, and then it is
probably better to use an URLConnection, not a plain socket connection.

Quote:>This would mean that multi-player games would require the user
>to set some flag or click some verification to allow additional ports,
>but then the user would be warned. Or does the very remote possibility
>of these sort of attacks make the restriction to the same port not
>worth the bother? Or are there additional problems I haven't
>considered?

I do think disallowing a few ports that are known security problems, or
giving the user a _strong_ warning about them, is a good idea.

The underlying problem is that there is no way for the browser to specify
that the server should not trust the applet (because Internet protocols were
not designed for the possibility of running untrusted programs). See another
of my posts on comp.lang.java for a possible solution.

David Hopwood


 
 
 

Java Security Loophole?

Post by Cameron Perki » Tue, 06 Feb 1996 04:00:00


: It is no more difficult for Joe to telnet to his own SMTP port (or that of
: whatever host he likes, for that matter), and forge the same thing - including
: the Received: entry.

: If you receive an unwelcome or forged mail, then (at least) _all_ the hosts
: on the Received lines are suspects.


outgoing logs and see that the messages did, in fact, originate there.
However, there's still the issue that it may be a compromised account,
but it still adds a layer of evidence pointing toward the innocent user.
Also, checking login logs, in some cases, could show that the innocent
user's account wasn't compromised.

--

 
 
 

Java Security Loophole?

Post by Godmar Ba » Wed, 07 Feb 1996 04:00:00



   : It is no more difficult for Joe to telnet to his own SMTP port (or that of
   : whatever host he likes, for that matter), and forge the same thing - including
   : the Received: entry.

   : If you receive an unwelcome or forged mail, then (at least) _all_ the hosts
   : on the Received lines are suspects.


   outgoing logs and see that the messages did, in fact, originate there.

 Logs about outgoing socket connections are rarely kept.
Remember that the Java applet is not using a mail agent on innocent.com.

However, the incoming logs on cracker.com will show that it originated
from innocent.com; despite of what the Receive line says.


particular if identd authentification is used.

Whether one should take getting fired on such an issue is a different
question.

 - Godmar
--

// University of Utah,  Computer Systems Laboratory (CSL)

 
 
 

Java Security Loophole?

Post by Jason Truesde » Thu, 08 Feb 1996 04:00:00


Java opens doors for distributed computing... so it must open doors for
distributed cracking...  Say http://www.cracker.com/ has a java script that
makes each client that picks up the script make, say, 20,000 attempts at
guessing a given encrypted root password, a specific one, by generating a
number of possible passwords in a specific order and encrypting them.  Say this script is on
each page at http://www.cracker.com/ and all of the pages get a total of
1,000,000 hits a month.  

that means 20,000,000,000 password guesses a month, assuming people don't cancel
the script before it finishes.  I think the number of possible 5-8 character
passwords was some number like x * 10 ^ 12, and considering that's only 2 x
10 ^ 11, there is still a ways to go...

Granted, the number of sites (especially run by hackers) getting 1,000,000
sites a month is going to be pretty small, and the likelyhood that users are
going to be patient enough to let a slow Java script run long enough to make so
many guesses is going to be pretty small, but if the site can somehow keep a
record of how far each computer got, what range of guesses they tried, etc,
they'd be well on their way to systematic hacking.  So in a few years, when
computers get fast enough and web sites receive enough hits, and a few
enterprising web site administrators feel like being hackers, perhaps
finding several people interested in cracking root at a specific site, this
doesn't seem impossible... Just, again, farfetched.

--
---------------------------------------------------------------------------
Jason Truesdell               | (phone) +49 (6421) 682 564

35039 Marburg    GERMANY      | http://stud-mailer.uni-marburg.de/~s1185659
                   * So Many Revolutions, So Little Time *

 
 
 

Java Security Loophole?

Post by Goran Svenss » Fri, 09 Feb 1996 04:00:00


This is a report of a posting I made, that unfortunately did not end up here.



>Java allows applets to open socket connections to the machine from

>showed how this could be used to create an applet that sent you mail
>(with the hostname of the client) everytime somebody accessed your
>WWW page.

>This raised a question about security in my mind. Here are two
>possible scenarios where this could be used in a malicious
>manner. Both assume Joe Cracker writes a malicious applet hosted on
>www.cracker.com, and is accessed by J. Random User at
>innocent.com.

[ A lot of interesting lines removed ]

Quote:>(B) Joe puts an applet on his page that, when it is loaded by a user
>from innocent.com, connects to the telnet port and tries to log in as
>root using random passwords. The system admin on cracker.com notices
>this and contacts the sysadmin at innocent.com. Two hours later,
>J. Random is called to his bosses office, where his system
>administrator shows logs showing his account connected to crack>administrator shows logs showing his account connected to cracker.com
>and tried to get root. J. Random denies all knowledge, and his boss
>has to choose whether to believe him or the system logs. J. Random
>gets fired.

[SNIP]

Quote:>Now, I am not claiming that this is a huge security hole. But p>Now, I am not claiming that this is a huge security hole. But perhaps
>it opens the door a crack by faking cracking activity that would be
>attributed to the wrong person. So my question is whether is is possible

In my opinion, the attribution of the deed to the wrong person iIn my opinion, the attribution of the deed to the wrong person is not that
much of a problem, the knowledge that there are a lot of possibilities
to masquerade as someone else is widespread.

BUT, there is an other, far more serious threat. If J. Random (l)User is
behind a firewall, the Java applet can open a socket connection to host
that are not available from the outside, and for example, fake a rsh command.

If that is possible for an applet to do, I would call that a __major__
security break.

/gs

--
---------------------------------------------+---------------------------------
  Goran Svensson                             ! I can speak for myself, and I do
  BTJ System AB                              +---------------------------------

  Snail: Box 4066, S-227 21 Lund, Sweden     ! the right to change it, doubt it
  Phone: +46 46 180 000, Fax: +46 46 180 333 ! or deny it at any time.
---------------------------------------------+---------------------------------
   Believe nothing, no matter where you read it, or who said it, no matter
   if I have said it, unless it agrees with your own reason and your own
   common sense.
                                          --Buddha

 
 
 

Java Security Loophole?

Post by Tony Ga » Fri, 16 Feb 1996 04:00:00




|> >BUT, there is an other, far more serious threat. If J. Random (l)User is
|> >behind a firewall, the Java applet can open a socket connection to host

That's not Marcus J. Random is it?
--

Tony Gast                       (606)344-4528x4667
Square D Co.
Sr. UNIX Systems Administrator (Guy, dude, etc)

 
 
 

Java Security Loophole?

Post by James R Grint » Fri, 23 Feb 1996 04:00:00



> This is supposed to be a function of the JAVA virtual machine.  The
> Netscape JVM, for example, only allows the applet to open a socket
> connection to the host from which the applet was loaded.

what is it supposed to do if a proxy was used to make the http request?
Let the java app only connect to the proxy, or only connect to the
remote host? (and how would it know that the proxy wasn't subverted
to return the wrong java app?)

-- jrg.

 
 
 

Java Security Loophole?

Post by Barry Margol » Tue, 27 Feb 1996 04:00:00




Quote:>what is it supposed to do if a proxy was used to make the http request?
>Let the java app only connect to the proxy, or only connect to the
>remote host?

To be useful, it would have to connect to the remote host -- it's unlikely
that the proxy also provides a proxy for all the services the remote system
is implementing.

Of course, if the reason for the proxy is that there's a firewall blocking
outgoing connections, that connection attempt will fail.  

Quote:>          (and how would it know that the proxy wasn't subverted
>to return the wrong java app?)

Proxies are part of your local configuration.  You're pretty much forced to
trust them as much as you trust all the other components of your local
network.
--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA

Phone (617) 873-3126 - Fax (617) 873-6351
 
 
 

Java Security Loophole?

Post by JaD » Tue, 27 Feb 1996 04:00:00





:|> >BUT, there is an other, far more serious threat. If J. Random (l)User is
:|> >behind a firewall, the Java applet can open a socket connection to host

:That's not Marcus J. Random is it?
:--

:Tony Gast                      (606)344-4528x4667
:Square D Co.
:Sr. UNIX Systems Administrator (Guy, dude, etc)
--
         />             JaDe     |     Star                 <\
        /<                         \|/                          >\
 *[/////|:::====================- --*-- -=====================:::|\\\\\]*
        \<                         /|\                          >/

 
 
 

1. Java, Java, Java, Java, Java, Java .....

In the systems being developed here, everything is coded in Java. There
are about 100 Java applications each running its own virtual machine.

I'm supposed to work with test and performance analysis of these systems
and I'm using tools that log system behaviour on process level.

The problem is that all I see is 100 processes named Java with some
small variations in command line parameters.

Is there a safe way to alter the process names either at startup or at
runtime ?
What could be the consequences of doing such a thing ?

//Hans Hagberg

2. xwebser help!

3. sunRPC Security loophole

4. 2.5.11 and smbfs

5. Appletalk (netatalk) Security Loophole

6. where do i find samba for SCO OpenServer 5 ?

7. Security Loopholes in the Past

8. Pop3 problem

9. HELP - Security Loophole for ftp

10. op systems security loopholes

11. Appletalk (netatalk) Security Loophole

12. Is .htaccess a security loophole?

13. (Fwd) Another Java security bug - ALL JAVA BROWSERS (fwd)