Scott Barman 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??
Not really - microsoft attempted to deflecte blame inappropriately and
ineffectually. In contrast, Sun has accepted more blame than they
really should have.
> [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!
Yes, but be careful: what if there's an http proxy in between? In other
words, you can't just getpeername(), like might be initially expected.
Presumably sun tried to work around this, by passing the initiating
machine's _name_.
However, given the current (insecure) state of the DNS, they should have
been passing back the _ip_address_ of the initiating machine. This
appears to be the full extent of sun's error on this issue - not realize
that the DNS could be used to provide incorrect information.
They could also continue passing the _name_, and then do a PTR check,
but passing the _ip_address_ in the first place eliminates a some
opportunities for trouble.
> 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.
Because you should not _have_ to do a reverse lookup. Supporting
detail:
1) If you check around in the bind archives, you'll find the use of PTR
records for security is deprecated.
2) The PTR check isn't sufficient to make things really solid anyway,
even from a DNS-perspective - it's still possible to fake out the DNS,
you just have to do it some other way, if there's a PTR check added.
3) There is no good reason why the DNS should allow you to publish data
about IP addresses that you haven't been delegated. Sure, there's a bit
of existing practice that makes legitimate (as it were) use of this
"flexibility", but it should not be allowed without specific delegation.
That is, if I've been delegated 128.200.34.36 by the powers that be,
there really isn't any good reason way anyone anywhere in the world can
publish DNS information about this IP address.
> 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??
I hope everyone does.
We configure many of our machines to drop connections from machines
without PTR's. I realize this contradicts my previous intimation that
PTR's should not be relied upon for security. (Hey, it's far from
infallible, but it's better than not having it at all, and it "came with
the territory" when installing TCP wrappers, which are useful for other
purposes).
> 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.
Quite a lot, yes.
> 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.
It's been hashed out 'til many are sick of hearing about it.
References:
|
|
