CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.15)  
ID

CWE-374: Passing Mutable Objects to an Untrusted Method

Weakness ID: 374
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product sends non-cloned mutable data as an argument to a method or function.
+ Extended Description
The function or method that has been called can alter or delete the mutable data. This could violate assumptions that the calling function has made about its state. In situations where unknown code is called with references to mutable data, this external code could make changes to the data sent. If this data was not previously cloned, the modified data might not be valid in the context of execution.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Memory

Potentially data could be tampered with by another function which should not have been tampered with.
+ Potential Mitigations

Phase: Implementation

Pass in data which should not be altered as constant or immutable.

Phase: Implementation

Clone all mutable data before passing it into an external function . This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.
+ Relationships
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.668Exposure of Resource to Wrong Sphere
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.371State Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
private:
int foo;
complexType bar;
String baz;
otherClass externalClass;


public:
void doStuff() {
externalClass.doOtherStuff(foo, bar, baz)
}

In this example, bar and baz will be passed by reference to doOtherStuff() which may change them.


Example 2

In the following Java example, the BookStore class manages the sale of books in a bookstore, this class includes the member objects for the bookstore inventory and sales database manager classes. The BookStore class includes a method for updating the sales database and inventory when a book is sold. This method retrieves a Book object from the bookstore inventory object using the supplied ISBN number for the book class, then calls a method for the sales object to update the sales information and then calls a method for the inventory object to update inventory for the BookStore.

(bad code)
Example Language: Java 
public class BookStore {
private BookStoreInventory inventory;
private SalesDBManager sales;
...
// constructor for BookStore
public BookStore() {
this.inventory = new BookStoreInventory();
this.sales = new SalesDBManager();
...
}
public void updateSalesAndInventoryForBookSold(String bookISBN) {

// Get book object from inventory using ISBN
Book book = inventory.getBookWithISBN(bookISBN);
// update sales information for book sold
sales.updateSalesInformation(book);
// update inventory
inventory.updateInventory(book);
}
// other BookStore methods
...
}
public class Book {
private String title;
private String author;
private String isbn;
// Book object constructors and get/set methods
...
}

However, in this example the Book object that is retrieved and passed to the method of the sales object could have its contents modified by the method. This could cause unexpected results when the book object is sent to the method for the inventory object to update the inventory.

In the Java programming language arguments to methods are passed by value, however in the case of objects a reference to the object is passed by value to the method. When an object reference is passed as a method argument a copy of the object reference is made within the method and therefore both references point to the same object. This allows the contents of the object to be modified by the method that holds the copy of the object reference. [REF-374]

In this case the contents of the Book object could be modified by the method of the sales object prior to the call to update the inventory.

To prevent the contents of the Book object from being modified, a copy of the Book object should be made before the method call to the sales object. In the following example a copy of the Book object is made using the clone() method and the copy of the Book object is passed to the method of the sales object. This will prevent any changes being made to the original Book object.

(good code)
Example Language: Java 
...
public void updateSalesAndInventoryForBookSold(String bookISBN) {

// Get book object from inventory using ISBN
Book book = inventory.getBookWithISBN(bookISBN);
// Create copy of book object to make sure contents are not changed
Book bookSold = (Book) book.clone();
// update sales information for book sold
sales.updateSalesInformation(bookSold);
// update inventory
inventory.updateInventory(book);
}
...

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPPassing mutable objects to an untrusted method
The CERT Oracle Secure Coding Standard for Java (2011)OBJ04-JProvide mutable classes with copy functionality to safely allow passing instances to untrusted code
Software Fault PatternsSFP23Exposed Data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-374] Tony Sintes. "Does Java pass by reference or pass by value?". JavaWorld.com. 2000-05-26. <https://web.archive.org/web/20000619025001/https://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html>. URL validated: 2023-04-07.
[REF-375] Herbert Schildt. "Java: The Complete Reference, J2SE 5th Edition".
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Name, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-06-21Mutable Objects Passed by Reference
Page Last Updated: July 16, 2024