[1781] in WWW Security List Archive
DNS Spoofing and Java
daemon@ATHENA.MIT.EDU (Richard Boardman)
Thu Apr 4 11:32:26 1996
From: Richard Boardman <boardmr@gb.swissbank.com>
Date: Thu, 4 Apr 1996 15:01:38 +0100
To: www-security@ns2.rutgers.edu
Cc: scott@di2.disclosure.com, boardmr@gb.swissbank.com
Errors-To: owner-www-security@ns2.rutgers.edu
Forwarded from the Firewalls list
=================================
From: Scott Barman <scott@di2.disclosure.com>
Date: Tue, 2 Apr 1996 13:56:35 -0500 (EST)
Subject: DNS Spoofing and Java
I was looking at Sun's statement regarding the bug they fixed and my
copy of the JDK (I still only have 1.0) and started thinking (I
know... that can be dangerous :-) about the attack using bogus DNS
entries. Sun states:
The problem is with a bug in the implementation of the
security model, not with the model itself.
(http://java.sun.com/sfaq/960327.html)
Besides sounding like Micro$haft and their response to Samba (it's the
client's fault, not ours) I was wondering, could this problem be
avoided if, to verify the address, the Verifier check and enforce
reverse name mappings??
[NOTE: The following is a review for those who haven't been following.
This is a very terse description. If you want more information
see the URL I give below.]
If we take the example of the folks at Princeton who discovered the
problem (http://www.cs.princeton.edu/~ddean/java/dns-scenario.html):
The victim: stooge.victim.org (IP 10.10.10.1)
target.victim.org (IP 10.10.10.2)
The attacker: www.attacker.org (IP 172.16.16.16)
Attacker creates a DNS entry for bogus.attacker.org and when querried
will return the pair of addresses (10.10.10.2, 172.16.16.16).
The unsuspecting client surfs over to www.attacker.org, downloads an
applet, and runs it. This applet askes to be connected to the system
bogus.attacker.org. The Verifier does a DNS qurry and gets the above
pair or addresses. Because the original connection came from
172.16.16.16, the Verifier will accept the request but connect to the
first address in the pair (10.10.10.2). The Princeton people attacked
an old sendmail bug, but you can do anything you want, including
attacking using the "r" commands!
[END OF REVIEW]
This brings up two questions (which I hope Sun already addressed):
1) Why not connect back to 172.16.16.16? If this is where the applet
came from, then why choose the first in the list? This is where I have
problems with Sun's statement. This is not the fault of the security
model, but of their code for "changing" the return address!
2) Why not do a reverse name lookup to verify this address? The way I
have internal DNS's setup, if you lookup 2.10.10.10.in-addr.arpa, the
internal DNS will return an internal name. That internal name will not
be the same as the attacker's name (see above), so the connection should
be rejected.
In fact, what would happen if you looked up 16.16.16.172.in-addr.arpa?
Would you get www.attacker.org or bogus.attacker.org? My guess would be
you would probably get www.attacker.org and no CNAME for
bogus.attacker.org, at which time all sorts of red flags, bell and
whistles should go off alerting the world to this problem, no?
Then the question becomes: How many people set up their internal DNS
with reverse name mapping??
Yes, I know this is a little bit outside of firewalls, but has to do
with setting up and securing systems inside of those firewalls.
BTW: If there's a Java security list and someone is on it, you have my
permission to forward this note to that list providing you keep my name
(and .sig) attached.
scott barman
- --
scott barman DISCLAIMER: I speak to anyone who will listen,
scott@disclosure.com and I speak only for myself.
barman@ix.netcom.com
Java: Sun's answer to the Unix Virus!
------------------------------
--
>Rick Boardman>>IT>>>>>>>>>>>>>>>>>>>>>boardmr@gb.swissbank.com>
<SBC-Warburg, London. EC4V 3SB. UK.<<<<<<<0171-711 2940<<<<<<<<<
