river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Date Mon, 04 Oct 2010 13:38:57 GMT
So let me get this clear, you don't want me to fix the deserialization 
attack because River isn't 100% provably secure?

Give me a break, I've only just started investigating it.

Name me one product that is 100% secure?

Can someone provide "a good reason" why I shouldn't attempt to fix the 
following deserialization attacks:

   1. Infinite loop recursion.
   2. Attempts to overflow memory by creating many objects.
   3. Deliberate concurrency deadlock.

All these I believe can be controlled by restricting the smart proxy to 
a single thread and passing all method invocations from a reflective 
proxy via a queue.  The client interacts with the reflective proxy, to 
the client, this is the service and the client is protected from those 
attacks because the client thread never touches the smart proxy.

   1. Infinite loops throw a StackOverflowError - terminate thread and
      smart proxy.
   2. Attempts to overflow memory by creating many objects - only causes
      a StackOverflowError for the smart proxy, terminate, throw an
      IOException, go find another service.
   3. Deliberate concurrency deadlock - ever tried this with only one
      thread?

Once trust is determined, after deserialization, with the existing trust 
mechanisms, then we are free to grant Permission to the smart proxy, and 
improve performance by allowing many threads.

Identifying a particular attack, then proving it doesn't work, will 
improve security.  I need tangible goals and identifiable issues to address.

N.B. Internet Banking isn't 100% secure, you take the following risks:

Keystroke logger at your PC.
A phishing attack.
Identity theft.
A DNS cache poisoning attack.
A registered signed certificate for an identically appearing site, but 
owned by an untrusted third party, you think is the bank.
An attacker breaking into the bank's webserver.
A compromised certificate.

I'm not creating a false sense of security, I'm investigating a security 
issue, why are you suddenly reading so much into it?

Peter.



Tom Hobbs wrote:
>>  Because it's possible and will improve security, I think we should
>> investigate it further, this could allow us to unmarshall the proxy and
>> determine trust without changing the Jini Service model.  There's still
>> Service UI to consider too, but that happens after determining trust.  We
>> need to be immune to DOS attacks during the period we're trying to determine
>> trust.
>>
>>     
>
> I don't want to discourage anyone from doing anything, but I find this
> concerning.  To my mind, something should either be 100% secure; like
> operating systems are (supposed to be), or there should be a clear "download
> and run at your own risk".  Things we pay for (buying stuff off the
> internet, online banking, hosted services etc) are supposed to be secure and
> there are clear SLAs describing what happens if it's not.  Everything else
> you download is very much "on your own head, be it".
>
> What I'm getting from these recent discussions is broadly this;
>
> - "We can protect against this kind of threat, but not that one."
> - "We can't protect, at all, against this other kind of thread."
> - "We can mitigate the consequences of this kind of thread."
>
> And that's only for the kinds of things we can think of.  I agree with Sim
> on this one, it feels like we're creating a false sense of security.  The
> danger I see in this is that people will either;
>
> 1) See our security designs, see that they're incomplete and announce that
> "River is insecure".
> 2) See our secuirty designs, miss what they do and do not provide, and
> announce that "River is bullet-proof".
>
> Both of these statements are wrong and both are dangerous.  I'm still of the
> opinion that we can provide secure services through trust (that's a
> lower-case, none Computer Science "trust") and not through code.  If,
> typically, people get their proxies from some kind of "app store" that they
> trust, the community can make sure that only trusted services can get onto
> the "app store".  If you want to use a less-known and maybe less trust
> worthy "app store" then that's up to you.
>
> I'm leaning towards programmatic security being an all-or-nothing affair.
>  Since it appears that we can't protect against everything; I'm reminded
> that we can lock and bolt the door as much as we like, but if we leave our
> Windows unsecure (ha ha) then the bad guys will still get in.
>
> Tom
>
>   


Mime
View raw message