You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Next »

Class methods that can be invoked from untrusted code to modify a static field must synchronize access to that field. This is necessary because there is no guarantee that untrusted clients will externally synchronize when accessing the field. Because a static field is shared by all clients, untrusted clients may violate the contract by failing to provide suitable locking.

According to Joshua Block [[Bloch 08]]:

If a method modifies a static field, you must synchronize access to this field, even if the method is typically used only by a single thread. It is not possible for clients to perform external synchronization on such a method because there can be no guarantee that unrelated clients will do likewise.

This guideline also applies to classes that explicitly document their lack of thread-safety. Documented design intent is irrelevant when dealing with untrusted code because an attacker can always chose to ignore the documentation.

Noncompliant Code Example

This noncompliant code example does not synchronize access to the static field counter.

/** This class is not thread-safe! */
public final class CountHits {
  private static int counter;
  
  public void incrementCounter() {
    counter++;
  }
}

This class definition does not violate CON01-J. Ensure that compound operations on shared variables are atomic which only applies to classes that promise thread-safety. However, this class has a mutable static field counter that is modified by the publicly accessible incrementCounter() method. Consequently, this class cannot be securely used by untrusted client code that may (purposely) fail to externally synchronize access to the field.

Compliant Solution

This compliant solution uses a static private final lock to protect the counter field and consequently, does not depend on any external synchronization. This solution also complies with CON04-J. Use private final lock objects to synchronize classes that may interact with untrusted code.

/** This class is thread-safe */
public final class CountHits {
  private static int counter;
  private static final Object lock = new Object();

  public void incrementCounter() {
    synchronized (lock) {
      counter++;
    }
  }
}

Risk Assessment

Failing to protect classes containing accessible static members can result in unexpected results when a client fails to obey the classes' synchronization policy.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CON32- J

low

probable

medium

P4

L3

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]]
[[Bloch 08]] Item 67: "Avoid excessive synchronization"

Issue Tracking

42%

Review List

  1. handler

    and specifies its lack of thread-safety in the documentation. => rephrase to : and documents its lack of thread-safety. <---- FIXED ~DS

    Priority MEDIUM
    svoboda
    Apr 01, 2010
  2. handler

    protecting fields is a weak word. Should be changed to synchronizing access to fields.

    Priority MEDIUM
    rcs
    Apr 01, 2010
  3. handler

    and not because it documents its lack of thread-safety; suggest removing this

    Priority MEDIUM
    rcs_mgr
    Apr 01, 2010
  4. handler

    The title can also be Ensure classes containing publicly accessible mutable static fields are thread-safe

    Priority MEDIUM
    Apr 01, 2010
  5. handler

    "Classes that use static fields that are both publicly accessible and mutable must always protect accesses to their fields, regardless of their documentation." => A class that is internally providing synchronization would not document that it is not thread-safe. So I don't understand why you added the words in bold.

    Priority MEDIUM
    svoboda
    Apr 02, 2010
  6. handler

    "The class relies on clients to externally synchronize the object and this class documents its lack of thread-safety" => "this class" occurs twice in the sentence. Should be "and documents its lack of thread safety".

    Priority MEDIUM
    svoboda
    Apr 02, 2010
  7. handler

    "any assurances that the class is safe-thread." => safe-thread should be thread-safe!

    Priority MEDIUM
    dmohindr
    Apr 03, 2010

VOID CON06-J. Do not defer a thread that is holding a lock      11. Concurrency (CON)      

  • No labels