----- Original message ----- > 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
+1 Well said, my thoughts exactly, grant Permission to Certificate & Principal combinations. We might need to work towards a PGP trust model. Cheers & Merry Christmas, Pete.
