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:[email protected]] Sent: Thursday, September 30, 2010 2:41 AM To: [email protected] 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:[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. > >
