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
