However memory exhaustion is a problem.
Even trusted code might create many objects and not null out their
references.
If Services and clients have identity, namely Public Key Certificates
and we had some kind of trust reporting service, then badly behaving
smart proxy's can be identified. The first person to report the problem
to, would be the service provider, then in case that doesn't work we
could set up a feedback service to encourage people to improve or
remove. Failing that the final case might be to black ban a service,
based on the message digest of it's proxy. This could be implemented as
a Service. Internet facing Service Registrar's could simply not allow
bad services to register. If the service provider fixes it's proxy, it
will have a different message digest and be given the opportunity to
work again with a new proxy codebase.
People will stop using a badly behaving service, because the app & jvm
will crash every time they try to use it.
What we really want to do is prevent access to information that
shouldn't be accessed and prevent mass DOS attacks, eg a big Jini botnet.
Individual DOS, not so bad, provided it is short lived and data is not
lost or corrupted.
We will need feedback services to report bad services to, so that
trusted Service Registrars don't deliver them to clients.
To deal with DOS, services will need to authenticate clients, and report
badly behaving clients (if those clients return an exported object).
Redundant services might also provide fail over protection. Badly
behaving clients must be denied access to Service Registrars. They will
need to obtain a new identity and start over, gaining trust.
In this case when I say authenticate, I mean with a Public Key
Certificate, perhaps we could use a PGP Provider?
7 Degrees of Separation, the web of trust?
Tim Blackman, was researching placing untrusted code into a Second JVM,
I believe because the isolates API was still-borne. I'm not sure how
the trusted and untrusted JVM's communicated.
Cheers,
Peter.
Peter Firmstone wrote:
Yes, it certainly can.
Regards,
Peter.
Christopher Dolan wrote:
private void readObject(ObjectInputStream in) {
new Runnable() {
public void run() {
while (true)
new Thread(this).start();
}
}.run();
}
At 1MB of stack RAM per thread, this will thrash most machines in no
time. Can a SecurityManager block thread creation?
Chris
-----Original Message-----
From: Peter Firmstone [mailto:[email protected]] Sent: Wednesday,
September 29, 2010 3:58 PM
To: [email protected]
Subject: Re: Towards Internet Jini Services (dos attacks)
Zoltan Juhasz wrote:
Sim,
I think the important danger in Jini is the use of objects. In simple
messaging communication (especially if non-binary), you don't have to
worry
about objects. In Jini, any method can take and object as a parameter
that
results in serialisation and unmarshalling at the receiver end. When
an
object has something nasty executing during within the readObject()
method,
it's too late to do anything.
This was a big problem in the days of single core, not as bad now.
Perhaps we need a software watchdog? Or an easy way to kill and
quarantine a misbehaving service? Or an unmarshalling executor
thread pool, which passes the object after it has been deserialized.
