A ThreadGroup
is nothing but a group of threads as defined by the class java.lang.ThreadGroup
. A group is assigned to a thread upon its creation. If the group name is not specified explicitly, the default group called main
is assigned by the JVM. One can use the convenience methods of the ThreadGroup
class to operate on all threads at once, such as, by using the interrupt
method. Another use is to build in layered security by confining threads into groups so that they do not interfere with each other.
[[JavaThreads 04]]
While there may be a few benefits, the associated dangers demand a deeper insight into the real utility of the ThreadGroup
class. Several of the ThreadGroup
APIs (allowThreadSuspension, resume, stop, suspend
) have been deprecated and the remainder are seldom used due to little desirable functionality. Ironically, a few APIs are not even thread-safe. [[Bloch 01]]
A programmer may sometimes wish to enumerate all the threads in a group as a precursor to other operations. This is accomplished by using the activeCount
method that "Returns an estimate of the number of active threads in this thread group. " [[API 06]]. Notice that there is no absolute word on whether it returns the exact count; the definition of active also has a different connotation here. A thread that has been constructed and not started is still counted by the activeCount
method as active.
According to [[API 06]], Class ThreadGroup
documentation:
The
enumerate method
"Copies into the specified array every active thread in this thread group and its subgroups. An application should use theactiveCount
method to get an estimate of how big the array should be. If the array is too short to hold all the threads, the extra threads are silently ignored."
Threads are removed from the thread array either when they are stopped or when their run
method has concluded. As a result, if a thread is not started, it will continue to reside in the array despite the loss of the original reference. [[JavaThreads 99]]
Noncompliant Code Example
This noncompliant code example shows a NetworkHandler
class that maintains a controller thread. This thread is responsible for spawning a new thread every time a new network connection request is received. For the sake of brevity, it is assumed that the controller thread invokes two methods (method1
and method2
) in succession and waits for a few milliseconds. The method1
method creates and starts two threads that are equivalent to two consequent connection requests, and so does the method2
method. All threads are defined to belong to the same group, Chief
.
There is a Time of Check-Time of Use (TOCTOU) vulnerability in this implementation since obtaining the count and enumerating the list are not an atomic operation. If new requests come in during the time interval between calling activeCount()
and enumerate()
, the total number of threads in the group will increase but there would be only two thread references in the enumerated list ta
. Print statements have been added before the invocation of activecount()
and enumerate()
to show this effect. Different runs of the program would produce different values due to the race conditions and demonstrate how a few incoming requests can get completely ignored. Any subsequent usage of the ta
array would lead to undesirable object retention.
class NetworkHandler implements Runnable { private static ThreadGroup tg = new ThreadGroup("Chief"); public void run() { try { method1(); method2(); Thread.sleep(500); } catch(InterruptedException e) {} } public static void method1() throws InterruptedException { Thread t1 = new Thread(tg, new HandleRequest(), "t1"); Thread t2 = new Thread(tg, new HandleRequest(), "t2"); t1.start(); t2.start(); } public static void method2() { Thread t3 = new Thread(tg, new HandleRequest(), "t3"); Thread t4 = new Thread(tg, new HandleRequest(), "t4"); t3.start(); t4.start(); } public static void main(String[] args) throws InterruptedException { Thread t = new Thread(tg, new NetworkHandler(), "t"); t.start(); System.out.println("Active Threads in Thread Group at point (1):" + t.getThreadGroup().getName() + " " + Thread.activeCount()); Thread ta[] = new Thread[Thread.activeCount()]; for(int i=0;i<500000;i++) {} // delay to demonstrate TOCTOU condition System.out.println("Active Threads in Thread Group at point (2):" + t.getThreadGroup().getName() + " " + Thread.activeCount()); int n = Thread.enumerate(ta); System.out.println("Enumerating..."); for(int i=0;i< n;i++) { System.out.println("Thread " + i + " = " + ta[i].getName()); } } } class HandleRequest implements Runnable { public void run() { System.out.println("Active Threads in Thread Group (Handler thread invoked this): " + Thread.currentThread().getThreadGroup().getName() + " " + Thread.activeCount()); } }
Compliant Solution
To be compliant, avoid using the ThreadGroup
class. Before Java 5.0, this class had to be extended as there was no other way to control the UncaughtExceptionHandler
. This application provided handler comes into picture when a thread exits due to an uncaught exception. In recent versions, the UncaughtExceptionHandler
is maintained on a per-thread basis using an interface enclosed by the Thread
class, leaving little to the ThreadGroup
class. [[Goetz 06]]
Risk Assessment
Using the ThreadGroup
APIs may result in race conditions, memory leakage and inconsistent object state.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
CON01- J |
low |
probable |
low |
P6 |
L2 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[API 06]] Methods activeCount
and enumerate
, Classes ThreadGroup and Thread
[[JavaThreads 04]] 13.1 ThreadGroups
[[Bloch 01]] Item 53: Avoid thread groups
[[Goetz 06]] 7.3.1. Uncaught Exception Handlers
[[SDN 06]] Bug ID: 4089701 and 4229558
CON00-J. Use synchronization judiciously 09. Concurrency (CON) CON02-J. Facilitate thread reuse by using Thread Pools