Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.11)  

CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context

Weakness ID: 567
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.

Extended Description

Within servlets, shared static variables are not protected from concurrent access, but servlets are multithreaded. This is a typical programming mistake in J2EE applications, since the multithreading is handled by the framework. When a shared variable can be influenced by an attacker, one thread could wind up modifying the variable to contain data that is not valid for a different thread that is also using the data within the variable.

Note that this weakness is not unique to servlets.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms



+ Common Consequences

Technical Impact: Read application data; Modify application data; DoS: instability; DoS: crash / exit / restart

If the shared variable contains sensitive data, it may be manipulated or displayed in another user session. If this data is used to control the application, its value can be manipulated to cause the application to crash or perform poorly.

+ Demonstrative Examples

Example 1

The following code implements a basic counter for how many times the page has been accesed.

(Bad Code)
Example Language: Java 
public static class Counter extends HttpServlet {
static int count = 0;
protected void doGet(HttpServletRequest in, HttpServletResponse out)
throws ServletException, IOException {
PrintWriter p = out.getWriter();
p.println(count + " hits so far!");

Consider when two separate threads, Thread A and Thread B, concurrently handle two different requests:

  • Assume this is the first occurrence of doGet, so the value of count is 0.

  • doGet() is called within Thread A.

  • The execution of doGet() in Thread A continues to the point AFTER the value of the count variable is read, then incremented, but BEFORE it is saved back to count. At this stage, the incremented value is 1, but the value of count is 0.

  • doGet() is called within Thread B, and due to a higher thread priority, Thread B progresses to the point where the count variable is accessed (where it is still 0), incremented, and saved. After the save, count is 1.

  • Thread A continues. It saves the intermediate, incremented value to the count variable - but the incremented value is 1, so count is "re-saved" to 1.

At this point, both Thread A and Thread B print that one hit has been seen, even though two separate requests have been processed. The value of count should be 2, not 1.

While this example does not have any real serious implications, if the shared variable in question is used for resource tracking, then resource consumption could occur. Other scenarios exist.

+ Potential Mitigations

Phase: Implementation

Remove the use of static variables used between servlets. If this cannot be avoided, use synchronized access for these variables.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory557Concurrency Issues
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base820Missing Synchronization
Research Concepts (primary)1000
ChildOfCategoryCategory852CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory986SFP Secondary Cluster: Missing Lock
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness VariantWeakness Variant488Exposure of Data Element to Wrong Session
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingVNA00-JEnsure visibility when accessing shared primitive variables
CERT Java Secure CodingVNA02-JEnsure that compound operations on shared variables are atomic
Software Fault PatternsSFP19Missing Lock
+ Content History
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes
2010-09-27CWE Content TeamMITREInternal
updated Other_Notes
CWE Content TeamMITREInternal
Made name and description more specific to match the essence of the rest of the entry.
2010-12-13CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Unsynchronized Access to Shared Data

More information is available — Please select a different filter.
Page Last Updated: May 05, 2017