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)
Date Thu, 30 Sep 2010 08:23:37 GMT
However memory exhaustion is a problem.

Even trusted code might create many objects and not null out their 

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.



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:jini@zeus.net.au] Sent: Wednesday, 
>> September 29, 2010 3:58 PM
>> To: river-dev@incubator.apache.org
>> 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.

View raw message