Take the 2-minute tour ×

I'm writing a server, which may be running hostile code. To prevent an attacker from throwing a thread into an infinite loop, I want to enforce a one-second execution time limit.

An InterruptedException can be caught inside an infinite loop, thus allowing an attacker to retain control of the thread. Thus Thread.interrupt() is not an acceptable solution.

My current implementation prevents hostile threads from acquiring any resources (including locks), uses Thread.stop() to terminate execution, and reverts any changes made by the thread. My main complaint is that it uses the deprecated Thread.stop() method; I don't like using deprecated code.

I'm wondering if there is a more industry-accepted solution, short of launching/killing an entirely new JVM, which would have too much overhead for my purposes.

share|improve this question
Run the untrusted code in a language that supports cheap sandboxes. Lua is nice for that, but I don't know if there is an implementation of it for the JVM. Btw how do you prevent it from acquiring resources or using dangerous APIs? –  CodesInChaos Jul 17 '11 at 16:58
I don't think limiting a hostile thread to 1 second does anything good. 1 second is a few billion instructions. –  toto2 Jul 17 '11 at 17:51
I use a combination of an extremely strict access controller and some bytecode manipulation. For the type of calls I'm considering, 1 second is a generous, but reasonable restriction. I'm just trying to avoid someone maliciously launching bunches of threads that will never complete. –  Jim Jul 17 '11 at 19:03
@Jim, if you are going to run totally unknown code, you need a separate process. No other way around, -XX:+TieredCompilation mitigates the issue, you might want to keep JVM on a ram-disk or at least SSD to speed up the start-up too. Also feel free to use Thread.stop(), if you can do Thread.suspend() walk the stack and determine it's ok to stop(). Yet, there are a lot ways to (maliciously) cause DoS even w/ the strictest SecurityManager. So a solution is running the unsecure code into a separate process (or multiple) and forcibly kill if it doesn't respond. –  bestsss Jul 17 '11 at 20:42

2 Answers 2

up vote 4 down vote accepted

The only way to kill a thread is to use a separate process and kill that process. Thread.stop() throws a ThreadDeath error which can be caught and ignored. i.e. catch(Throwable t) {}

For more details on what Thread.stop() actually does Does Thread.stop() really stop a Thread?

share|improve this answer
I've some success instrumenting the loaded bytecode to catch ThreadDead and rethrow it. –  bestsss Jul 17 '11 at 18:22
Ok, I didn't know about ThreadDeath, and java.lang.Error is already on my whitelist, so my initial solution is starting to feel too unsafe. Thanks for all the feedback! I'm thinking I should create some worker-processes, which I can delegate tasks to, and kill when necessary. JVM overhead and the additional serialization will be very unfortunate, but I don't see a safe alternative. –  Jim Jul 17 '11 at 19:08

You cannot guarantee that a thread can be stopped as several blocking methods (like sockets) do not respond to interrupt().

I would suggest a very strict security manager so you can be absolutely certain that the malicious code is sandboxed. If you need to be certain then consider a special classloader which ensures that only valid operations are being done.

share|improve this answer
I would suggest a very strict security manager so you can be **absolutely certain**, impossible in java unless the bytecode is instrumented. –  bestsss Jul 17 '11 at 18:21
... it is sandboxed. –  Thorbjørn Ravn Andersen Jul 17 '11 at 18:23
but that doesn't prevent DoS like not-stopping threads that don't won't to be stopped. –  bestsss Jul 17 '11 at 18:25
Yes, I'm using an incredibly strict access controller and am doing bytecode manipulation to prevent many other operations. The goal here is, as bestsss observed, to prevent DoS like not-stopping threads. –  Jim Jul 17 '11 at 18:57

Your Answer


