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 Fri, 01 Oct 2010 10:41:55 GMT
Perhaps Oracle might have the money to complete the MVM Isolates API for 
Java SE and EE.

Isolates present the opportunity to restrict resources, which could fix 
the issues with excess resource consumption as DOS.

Until then the remaining ways to combat the memory consumption problem.

Reboot, report and be careful who you trust.

N.B. They can't do this with a reflective proxy, so don't grant their 
Principal DownloadPermission if you don't trust them.

Cheers,

Peter.

Christopher Dolan wrote:
> 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