Page History

{quote}
This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its {{get}} or {{set}} method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically {{private static}} fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

 
{quote}

The use of {{ThreadLocal}} objects is insecure in classes whose objects are required to be executed by several threads, in a thread pool. The technique of thread pooling allows threads to be reused when thread creation cost is too high or creating an unbounded number of threads is a potential threat to the reliability of the system. Every thread that enters the pool expects to see an an object in its default, initialized form. However, when {{ThreadLocal}} objects are set from a thread which is subsequently made available for reuse, the reusing thread which takes its place may see the most recent state that was set by the previous thread instead of the expected, default state. \[[JPL 06|AA. Java References#JPL 06]\]

h2. Noncompliant Code Example

This noncompliant code example consists of an enumeration {{Day}} of days, a class {{Diary}} and a class {{DiaryPool}}. The class {{Diary}} uses a {{ThreadLocal}} variable to store thread-specific information, such as each thread's current day. The initial value of the current day is Monday, and this can be changed later by using the {{setDay()}} method. The thread also contains a thread-specific {{threadSpecificTask()}} instance method that performs a thread specific task.

 

The class {{DiaryPool}} consists of two methods {{doSomething1()}} and {{doSomething2()}} that start a thread each, respectively. The method {{doSomething1()}} changes the initial (default) value of the day in the diary to Friday and invokes the {{threadSpecificTask()}} method. However, the method {{doSomething2()}} relies on the initial value of the day (Monday) in the diary and invokes the {{threadSpecificTask()}} method. The {{main()}} method creates one thread using {{doSomething1()}} and two more using {{doSomething2()}}.

{code

:bgColor

=#FFCCCC

}
public enum Day {
  MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY;

  public static Day getInitialDay(Day d) {
    switch(d) {
      case MONDAY: return MONDAY;
      case TUESDAY: return TUESDAY;
      // ...
      default: return null;
    }
  }
}

public class Diary {
  private static ThreadLocal<Day> days = 
    new ThreadLocal<Day>() {
      // Initialize to Monday 
      protected Day initialValue() {
        return Day.getInitialDay(Day.MONDAY);
      }
    };

  private static Day currentDay() {
    return days.get();
  }

  public static void setDay(Day newDay) {
    days.set(newDay);
  }
    
  // Performs some thread-specific task
  public void threadSpecificTask() {
    // Do task ...
    System.out.println("The current day is: " + currentDay());
  }
}


class DiaryPool {
  final int NoOfThreads = 2; // Maximum number of threads allowed in pool
  final Executor exec;
  final Diary diary;

  DiaryPool() {
    exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
    diary = new Diary();
  }

  public void doSomething1() {
    exec.execute(new Runnable() {
      public void run() {
        Diary.setDay(Day.FRIDAY);
        diary.threadSpecificTask();
      }
    });
  } 

  public void doSomething2() {
    exec.execute(new Runnable() {
      public void run() {
        diary.threadSpecificTask();
      }
    });
  }

  public static void main(String[] args) {
    DiaryPool dp = new DiaryPool();
    dp.doSomething1(); // Thread 1, requires current day as Friday
    dp.doSomething2(); // Thread 2, requires current day as Monday
    dp.doSomething2(); // Thread 3, requires current day as Monday
  } 
}

{code}

This noncompliant code example sometimes prints:

 Risk Assessment

When objects of classes that use {{ThreadLocal}} data are executed in a thread pool by different threads, they may assume stale states, resulting in corrupt data.

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON27- J | high | probable | medium | {color:red}{*}P12{*}{color} | {color:red}{*}L1{*}{color} |

h3. Automated Detection

TODO

h3. Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+FIO38-J].

h2. References

\[[API 06|AA. Java References#API 06]\] class {{java.lang.ThreadLocal<T>}}
\[[JPL 06|AA. Java References#JPL 06]\] 14.13. ThreadLocal Variables

----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|FIO36-J. Do not create multiple buffered wrappers on an

 InputStream]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|09. Input Output (FIO)]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|09. Input Output (FIO)]