On 12/24/2011 2:14 AM, Dan Creswell wrote:
So...
On 23 December 2011 11:32, Peter Firmstone<j...@zeus.net.au> wrote:
One question I've asked myself when creating my own policy implementation
was CodeSource.implies(CodeSource cs), the implementation seemed like a bad
idea, it uses DNS, an attacker could use DNS cache poisoning to gain
elevated permission using an untrusted CodeSource URL, simply because the
policy thinks the CodeSource is implied. I changed PolicyFile to
specifically not use CodeSource.implies(). In reality a signer Certificate
is required to identify the CodeSource with any level of trust.
Well, I think a more general point here would be that JDK's default
set of behaviours are designed to "protect" against DNS based attacks
(i.e. a successful lookup result is cached forever and so changes
can't leak in). This is bogus, because if the first lookup is
compromised you're dead and buried.
I think it's fundamental to understand that a lot of the DNS caching behavior
was born in the Applet world. When Java first hit the scenes, we had the
problem that people could demonstrate that they could "know" the address of the
socket on the remote end, and thus could use that (this was before NAT was in
use, or at least wide spread), and poison the DNS so that subsequent lookups
returned addresses on the local network, instead of the correct address of the
original server.
That's one path of exploitation, but as Dan says, there are others in the Jini
world where the first lookup, being poisoned, can cause exploitative code to be
downloaded.
I think that it's vital to understand, that whether you cache the first, second
or fifth lookup, each situation presents a different set of challenges in
providing security. Ultimately, Jini needs, in my opinion, to focus
authentication above the network layer, and use signed jars, encrypted paths,
and cert based auth, so that the network path, can not be a part of the
exploitation, and instead, each end of a "communication", is responsible for
trusting the other, through negotiations carried through the network, instead of
using information about the network to guarantee trust.
Gregg Wonderly
