Many programs must address the problem of handling a series of incoming requests. One simple concurrency strategy is the Thread-Per-Message design pattern, which uses a new thread for each request [Lea 2000a]. This pattern is generally preferred over sequential executions of time-consuming, I/O-bound, session-based, or isolated tasks.

However, the pattern also introduces overheads not seen in sequential execution, including the time and resources required for thread creation and scheduling, for task processing, for resource allocation and deallocation, and for frequent context switching [Lea 2000a]. Furthermore, an attacker can cause a denial of service (DoS) by overwhelming the system with too many requests at once, causing the system to become unresponsive rather than degrading gracefully. From a safety perspective, one component can exhaust all resources because of an intermittent error, consequently starving all other components.

Thread pools allow a system to limit the maximum number of simultaneous requests that it processes to a number that it can comfortably serve rather than terminating all services when presented with a deluge of requests. Thread pools overcome these issues by controlling the maximum number of worker threads that can execute concurrently. Each object that supports thread pools accepts a Runnable or Callable<T> task and stores it in a temporary queue until resources become available. Additionally, thread life-cycle management overhead is minimized because the threads in a thread pool can be reused and can be efficiently added to or removed from the pool.

Programs that use multiple threads to service requests should—and programs that may be subjected to DoS attacks must—ensure graceful degradation of service during traffic bursts. Use of thread pools is one acceptable approach to meeting this requirement.

Noncompliant Code Example (Thread-Per-Message)

This noncompliant code example demonstrates the Thread-Per-Message design pattern. The RequestHandler class provides a public static factory method so that callers can obtain a RequestHandler instance. The handleRequest() method is subsequently invoked to handle each request in its own thread.

class Helper {
  public void handle(Socket socket) {
    // ...
  }
}

final class RequestHandler {
  private final Helper helper = new Helper();
  private final ServerSocket server;

  private RequestHandler(int port) throws IOException {
    server = new ServerSocket(port);
  }

  public static RequestHandler newInstance() throws IOException {
    return new RequestHandler(0); // Selects next available port
  }

  public void handleRequest() {
    new Thread(new Runnable() {
        public void run() {
          try {
            helper.handle(server.accept());
          } catch (IOException e) {
            // Forward to handler
          }
        }
    }).start();
  }

}

The thread-per-message strategy fails to provide graceful degradation of service. As threads are created, processing continues normally until some scarce resource is exhausted. For example, a system may allow only a limited number of open file descriptors even though additional threads can be created to serve requests. When the scarce resource is memory, the system may fail abruptly, resulting in a DoS.

Compliant Solution (Thread Pool)

This compliant solution uses a fixed thread pool that places a strict limit on the number of concurrently executing threads. Tasks submitted to the pool are stored in an internal queue. Storing tasks in a queue prevents the system from being overwhelmed when attempting to respond to all incoming requests and allows it to degrade gracefully by serving a fixed maximum number of simultaneous clients [Java Tutorials].

// class Helper remains unchanged

final class RequestHandler {
  private final Helper helper = new Helper();
  private final ServerSocket server;
  private final ExecutorService exec;

  private RequestHandler(int port, int poolSize) throws IOException {
    server = new ServerSocket(port);
    exec = Executors.newFixedThreadPool(poolSize);
  }

  public static RequestHandler newInstance(int poolSize) 
                                           throws IOException {
    return new RequestHandler(0, poolSize);
  }

  public void handleRequest() {
    Future<?> future = exec.submit(new Runnable() {
        @Override public void run() {
          try {
            helper.handle(server.accept());
          } catch (IOException e) {
            // Forward to handler
          }
        }
    });
  }
  // ... Other methods such as shutting down the thread pool 
  // and task cancellation ...
}

According to the Java API documentation for the Executor interface [API 2014]:

[The interface Executor is] an object that executes submitted Runnable tasks. This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An Executor is normally used instead of explicitly creating threads.

The ExecutorService interface used in this compliant solution derives from the java.util.concurrent.Executor interface. The ExecutorService.submit() method allows callers to obtain a Future<V> object. This object both encapsulates the as-yet unknown result of an asynchronous computation and enables callers to perform additional functions such as task cancellation.

The choice of newFixedThreadPool is not always appropriate. Refer to the Java API documentation [API 2014] for guidance on choosing among the following methods to meet specific design requirements:

  • newFixedThreadPool()
  • newCachedThreadPool()
  • newSingleThreadExecutor()
  • newScheduledThreadPool()

Risk Assessment

Using simplistic concurrency primitives to process an unbounded number of requests could result in severe performance degradation, deadlock, or system resource exhaustion and DOS.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

TPS00-J

Low

Probable

High

P2

L3

Automated Detection

Sound automated detection is infeasible; heuristic checks could be useful.

ToolVersionCheckerDescription
Parasoft Jtest

2024.1

CERT.TPS00.ISTARTDo not call the 'start()' method directly on Thread class instances

Related Guidelines

MITRE CWE

CWE-405, Asymmetric Resource Consumption (Amplification)
CWE-410, Insufficient Resource Pool

Bibliography

[API 2014]

Interface Executor

[Goetz 2006a]

Chapter 8, "Applying Thread Pools"

[Java Tutorials]

Thread Pools

[Lea 2000a]

Section 4.1.3, "Thread-Per-Message"
Section 4.1.4, "Worker Threads"



13 Comments

  1. I would like comments on the Compliant Solution(s) for the second Noncompliant Example.

    Might also make more sense to implement Callable instead of Runnable to allow Exceptions.

  2. Two points:

    (1) How exactly do you define the border between security rules and what we could call

    safety rules? A safety rule is here meant as a rule preventing a bug to occur (not to prevent an attack). One can of course say that safety rules should form a subset of security rules since any form of bug can be revealed with certain input, and and attacker can control input. Is this the idea?

    (2) This rule seems to state how to use thread pools in the java.util.concurrent package. Should there then be a rule for each concept provided by this package? 

    1. Here are my thoughts with inputs from Robert C. Seacord:

      Regarding 1) -

      1. Safety and security have different goals in general yet they have some common ground. The aim of security as ISO/IEC PDTR 24772 defines it is to guarantee Confidentiality, Integrity and Availability of data (CIA triad). IMO, the problem with this definition is that it does not cover authenticity, non-repudiation and several other security properties and is very general. Safety overlaps the "Availability" and "Integrity" aspects of this definition because the primary aim of safety is fault tolerance.

      2. Guidelines that address security also affect safety as you note. Instead of an attacker, whose sole aim is to break the system, safety deals with probable errors that can cause the system to fail. The role of the attacker is assumed by an unpredictable hostile physical environment, for example. That said, some security attacks require the attacker to craft special input which may be inconceivable in safety-critical equipment simply because there are no "malicious" users.

      3. The rules for safety are more stringent than those for security. For example, runtime exceptions and multi-threading may not be used in safety critical code whereas user/server applications can freely use them provided they don't violate any secure coding guidelines.

      4. JSR-302 by the Open Group is attempting to define a specification of safety critical Java which has very little to do with security (it almost assumes that there are no malicious users). I think it would also be slightly overkill to use a security manager for safety, but there might be some applications that demand the confinement.

      Regarding 2) -

      1. This guideline exists because an attacker can cause a denial of service by sending too many requests all at once. So instead of degrading gracefully, the system goes down at once hurting "Availability". Thread pools allow the system to service as many requests as it can comfortably sustain, instead of stopping all services when faced with a deluge of requests. From the safety point of view, it is possible for one component to exhaust all resources because of some intermittent error, starving all others from using them.

      2. There won't be other API rules from this package unless they significantly help reduce the threat of denial of service or are inherently buggy.

  3. IMHO the material in the Regarding 2) - response should appear in the rule so that the reader can readily identify the exploit that is available to an attacker should this vulnerability be ignored.

    "1. This guideline exists because an attacker can cause a denial of service by sending too many requests all at once. So instead of degrading gracefully, the system goes down at once hurting "Availability". Thread pools allow the system to service as many requests as it can comfortably sustain, instead of stopping all services when faced with a deluge of requests. From the safety point of view, it is possible for one component to exhaust all resources because of some intermittent error, starving all others from using them."

    • What exactly is the Thread-per-Message design pattern? Does Lea provide a definition?
    • Good rule, but the title is not a good summary...how about this one?

    Use thread pools to enable graceful degradation of services during traffic bursts

    In particular, we seem to be warning about the potential for DOS in the thread-per-message design pattern.

    • In fact, while a thread pool is the most general solution, it is not strictly necessary. A limited, but equally-compliant solution would be to utilize one single thread to handle requests and have a BlockingQueue store additional requests. (Not sure its worthwhile building a CS on this. It won't kill the system, but may cause unacceptable throughput.)
    • The getInstance() should maintain a static list...what if someone requests getInstance(80) twice? Could we just eliminate this method?
    • Some more info about the Geronimo vulnerability would be useful. (I bet there are lots of vuls about this problem).
      • The book's not with me right now. Place holder; will reply later. Nope, no definition has been provided.
      • Good idea, though the executor framework seems to be the first choice irrespective of traffic bursts or graceful degradation because it is cleaner for serious multithreaded business. Maybe we should recommend thread pools outright, or as you suggest, warn against patterns such as thread-per-message.
      • Sounds like AWT's idea. I bet doing it yourself won't be as optimal and worth the effort.
      • Good point but there will be an exception which is ok. The server code is running this and I won't expect any untrusted code with this code really. Furthermore, a server that passes an argument of 0 to ServerSocket's ctor ensures that a free port is chosen. We can hard code this for the purpose of this example.
      • IIRC, the related vulns section is for this purpose. One thing I am not sure about is - can we expand the description of the vuln to provide a summary?
      1. We have several rules in the C standard that provide a short paragraph describing real-world vulnerabilities. So I think a description would not be amiss here.

        When I checked the link, I found a Bugzilla page with lots of info, and no clear direction where the vul lay. So a paragraph that sumamrizes the Geronimo vul would definitely be worthwhile.

        1. Lacking a clear explanation, I've removed this:

          Related Vulnerabilities

          Apache Geronimo 3838 potential denial of service attack in Tomcat session handling.

          1. Agreed....AFAICT this could have been nothing more than your plain vanilla memory leak. A ThreadPool would help, but might not have solved the problem.

  4. We might want to retain Executors.newCachedThreadPool as an NCE because it should not be used in production environments.

  5. let me check if my understanding is correct...

    the following sentence, at the end of the first paragraph,

    This pattern is generally preferred over sequential executions of time-consuming, I/O-bound, session-based, or isolated tasks.

    can be rewritten to:

    This pattern is generally preferred over sequential executions of tasks, when each task has any one of the following properties:

    • time-consuming
    • I/O-bound
    • session-based
    • isolated from other tasks
    1. Your understanding is correct.

      It's not explicit in the sentence, but the pattern is preferred to improve performance, and often to take advantage of multi-core CPUs.