...
Thread Pools overcome these issues as the maximum number of worker threads that can be initiated and executed simultaneously can be suitably controlled. Every worker accepts a Runnable object from a request and stores it in a temporary Channel like a buffer or a queue until resources become available. Because threads are reused and can be efficiently added to the Channel, most of the thread creation overhead is also eliminated.
Noncompliant Code Example
This noncompliant code example demonstrates the Thread-Per-Message design that fails to provide graceful degradation of service.
| Code Block | ||
|---|---|---|
| ||
class Helper {
public void handle(String request) {
//...
}
}
class GetRequest {
protected final Helper h = new Helper();
String request;
public synchronized String accept() {
String data = "Read data from pipe";
// Read the request data, else block
return data;
}
public void request() {
while(true) {
request = accept();
new Thread(new Runnable() {
public void run() {
h.handle(request);
}
}).start();
}
}
}
|
Compliant Solution
| Wiki Markup |
|---|
This compliant solution uses a _Fixed Thread Pool_ that places an upper bound on the number of simultaneously executing threads. Tasks submitted to the pool are stored in an internal queue. This prevents the system from getting overwhelmed when trying to respond to all incoming requests and allows it to degrade gracefully by serving a fixed number of clients at a particular time. \[[Tutorials 08|AA. Java References#Tutorials 08]\] |
...
| Code Block | ||
|---|---|---|
| ||
class GetRequest {
protected final Helper h = new Helper();
String request;
public synchronized String accept() {
String data = "Read data from pipe";
// Read the request data, else block
return data;
}
public void request() {
int NoOfThreads = 200;
Executor exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
while(true) {
request = accept();
exec.execute(new Runnable() {
public void run() {
h.handle(request);
}
});
}
}
}
|
Noncompliant Code Example
In reality, there are some problems associated with the use of the Executor interface. For one, tasks that depend on other tasks should not execute in the same Thread Pool. A task that submits another task to a single threaded Executor remains blocked until the results are received whereas the second task waits until the first one has concluded. This constitutes a deadlock.
...
| Code Block | ||
|---|---|---|
| ||
class NetworkServer extends InitialHandshake implements Runnable {
private final ServerSocket serverSocket;
private final ExecutorService pool;
public NetworkServer(int port, int poolSize) throws IOException {
serverSocket = new ServerSocket(port);
pool = Executors.newFixedThreadPool(poolSize);
}
public void run() {
try {
// Interdependent tasks
pool.submit(new SanitizeInput(password)); // Password is defined in class InitialHandshake
pool.submit(new CustomHandshake(password)); // for e.g. client puzzles
pool.execute(new Handle(serverSocket.accept())); // Handle connection
} catch (IOException ex) {
pool.shutdown();
}
}
}
|
Compliant Solution
Always try to submit independent tasks to the Executor. Choosing a large pool size can also help reduce thread starvation problems. Note that any operation that has further constraints, such as the total number of database connections or total ResultSets open at a particular time, impose an upper bound on the Thread Pool size as each thread continues to block until the resource becomes available. The other rules of fair concurrency, such as not running response sensitive tasks, also apply.
...
| Code Block | ||
|---|---|---|
| ||
class NetworkServer extends InitialHandshake implements Runnable {
private final ServerSocket serverSocket;
private final ExecutorService pool;
public NetworkServer(int port, int poolSize) throws IOException {
serverSocket = new ServerSocket(port);
pool = Executors.newFixedThreadPool(poolSize);
}
public void run() {
try {
// Execute interdependent subtasks as a single combined task within this block
pool.execute(new Handle(serverSocket.accept())); // Handle connection
} catch (IOException ex) {
pool.shutdown();
}
}
}
|
Risk Assessment
Using simplistic concurrency primitives (often incorrectly too) may lead to severe performance degradation, deadlocks and starvation, or exhaustion of system resources. This results in a denial-of-service attack.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON02- J | low | probable | high | P2 | L3 |
Automated Detection
TODO
Related Vulnerabilities
References
| Wiki Markup |
|---|
\[[API 06|AA. Java References#API 06]\] [Interface Executor|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html] \[[Lea 00|AA. Java References#Lea 00]\] Section 4.1.3 Thread-Per-Message and 4.1.4 Worker Threads \[[Tutorials 08|AA. Java References#Tutorials 08]\] [Thread Pools|http://java.sun.com/docs/books/tutorial/essential/concurrency/pools.html] \[[Goetz 06|AA. Java References#Goetz 06]\] Chapter 8, Applying Thread Pools \[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 405|http://cwe.mitre.org/data/definitions/405.html] "Asymmetric Resource Consumption (Amplification)", [CWE ID 410|http://cwe.mitre.org/data/definitions/410.html] "Insufficient Resource Pool" |
...