river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: Towards Internet Jini Services (dos attacks)
Date Thu, 30 Sep 2010 15:59:44 GMT
Just for the record, Peter is right. I just looked at the JDK 1.5 source
code for java.lang.Thread. The security permission you need to create a
thread or a thread group is
SecurityConstants.MODIFY_THREADGROUP_PERMISSION, aka
java.lang.RuntimePermission("modifyThreadGroup"). I hadn't known about
that. The "modifyThread" permission does not affect one's ability to
create and start threads.

So, that would argue for a tightened security context during
deserialization.  That would at least revert us to Peter's original
statement that only one core could be smacked with 100% load.  The RAM
usage would not be controllable, though.

Chris

-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au] 
Sent: Thursday, September 30, 2010 2:41 AM
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (dos attacks)

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.
>
>   


Mime
View raw message