In Article: <Pine .
SUN .
3 .
91 .
960402100639 .
4764B-100000 @
di2>, Scott Barman <scott @
di2 .
disclosure .
com> wrote:
# 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??
In some cases maybe. Practically, I don't think so.
# [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):
[ deletia - Attack scenario ]
# 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!
If I understand your point, you want to allow the server to be able to redirect
subsequent connections to machines/interfaces other than the one that was
originally connected to when downloading the applet. If this is the case, I
agree, this is probably a desirable goal.
# 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.
The problem is that there are several different "standard" ways of handling
in-addr.arpa PTR RRs. For example:
1) [ you are presuming that ] "www.foo.com" might map to three addresses,
(say) and that each of these would map back to "www.foo.com"
2) "www.foo.com" might map to three addresses, each of these might map back
to "www[123].foo.com" or "gateway.foo.com", or something entireley
different.
3) The forward mapping might be using CNAME or A RRs.
4) most addresses in my class C map to "aztech.net"
5) There may be (will be) others that I haven't thought of.
My basic point is that the only consistent thing is inconsistency.
# 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?
The algorithm for bell-ringing isn't a simple thing. eg. Should the browser
ring a bell if I download an applet from www.FOO.net, that subsequently
attempts to connect to an address whos PTR RR says that it's www.FOO.com?
# Then the question becomes: How many people set up their internal DNS
# with reverse name mapping??
Probably, the majority do, especially for their externally reachable systems.
# 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.
I agree, although some of my first posts on the subject were to the firewalls
list as well, some time before the Princeton group actually came up with an
exploit (See http://www.aztech.net/~steve/java/ for a timeline/details.)
I have asked one of the current writers that's working on PKC signed DNS RRs to
include a section on the "implimentation details" of verifying forward and
reverse DNS lookups. It's my suggestion that an application (eg. an applet)
that wants to verify that the address that it's connecting to is valid, only
has to check that the "owning" signer of the A RR and the PTR RR are the same
entity. This greatly simplifies the algorithm for "what matches, and/or is
allowable?"
Comments?
--
Steve @
AZTech .
Net
|
|
