Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=BejG9C=7F=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.121 as permitted sender)
Message-ID: <4EF6CCE7.7040903@wonderly.org>
Date: Sun, 25 Dec 2011 01:12:39 -0600
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Mozilla/5.0 (Windows NT 6.0;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: dev@river.apache.org
CC: Dan Creswell <dan.creswell@gmail.com>
Subject: Re: Implications for Security Checks - SocketPermission, URL and
 DNS lookups
References: <4EE2D1C9.1050402@zeus.net.au>
 <EFE4B26E587F034A9BDFEEE751D57E2702FBD8@WAL-MBS02.global.avidww.com>
 <CAEDB+kULNc51QVFphFEq5Cbhvf7ZujgXaZA_BHVAb-d36Ji+qg@mail.gmail.com>
 <EFE4B26E587F034A9BDFEEE751D57E270300B5@WAL-MBS02.global.avidww.com>
 <4EE71322.20408@zeus.net.au> <4EE75EE6.4040509@wonderly.org>
 <EFE4B26E587F034A9BDFEEE751D57E27030732@WAL-MBS02.global.avidww.com>
 <4EE7A712.2090407@zeus.net.au>
 <EFE4B26E587F034A9BDFEEE751D57E27030AED@WAL-MBS02.global.avidww.com>
 <1323942138.7030.5.camel@Nokia-N900-51-1> <4EF3E22E.6090900@zeus.net.au>
 <CAMPUXz97K+0kESVicik1M_q06iaAdLSxsAgZRE+KoZct2EoXdg@mail.gmail.com>
 <4EF466E0.6000901@zeus.net.au>
 <CAMPUXz_90K3+dT6fUvBOnoqGYEe4Q-zNEnOe_9T5WpYzCf3PnA@mail.gmail.com>
In-Reply-To: 
 <CAMPUXz_90K3+dT6fUvBOnoqGYEe4Q-zNEnOe_9T5WpYzCf3PnA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

On 12/24/2011 2:14 AM, Dan Creswell wrote:
> So...
>
> On 23 December 2011 11:32, Peter Firmstone<jini@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