river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Date Mon, 04 Oct 2010 14:06:54 GMT
Hi Peter,

Sorry if my emails of late resemble an attack, they're not intended as such.
 I'm just asking questions and trying to understand.

You're right, nothing is ever 100% provably secure - to my knowledge at
least.  Internet banking is not 100% secure; however, all things being
equal, it is considered to be "secure enough".

There is no reason why you shouldn't implement those changes.  As I
understand Apache, anyone who has the will and the way can do pretty much
whatever they want, while everyone else stands around talking about it.  My
only point was, as soon as we start to programatically mitigate those kinds
of attack we have to maintain that approach; along with plugging the extra
holes as and when they are found.  So the effort to do this kind of work is
actually ongoing and more than just addressing the attacks we currently have
identified.

The false sense of security I was talking about is linked to that.  If we
protect against the three attacks you list, then great, but users will
expect us to also protect against some fourth kind of attack.  If we miss
it, or ignore it, or decide "actually, we *can't* guard against this new
attack", we're left with an incomplete security model.  As a service
provider, I would personally find it confusing trying to keep track of which
kind of attack my infrastructure (River) guards me against and which ones it
doesn't.

To me, in my opinion, that sounds like a bit of a mess that I (personally)
don't want to get involved in.  What I am arguing is that we can avoid that
situation 'simply' by saying "Make sure you trust the person you get the
proxy from" and then assume that everything is okay from then on in.  This
makes the code changes you refer to as "nice to have" rather than "critical"
just get River to be viewed as "secure enough".

Things like RSA and so on are demonstrably secure (so far, anyway).  Can
anyone who is a Security Expert (i.e. not me) tell me/us if there is some
kind of way to demonstrate the security of the code.  Or are code
reviews/tests/written papers/etc enough?

Cheers,

Tom



On Mon, Oct 4, 2010 at 2:38 PM, Peter Firmstone <jini@zeus.net.au> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message