CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-919: Weaknesses in Mobile Applications (2.11)  
ID

CWE VIEW: Weaknesses in Mobile Applications

View ID: 919
Structure: Implicit Slice
Status: Incomplete
Presentation Filter:
+ View Data

View Objective

CWE entries in this view (slice) are often seen in mobile applications.

View Filter: .//@Architectural_Paradigm_Name='Mobile Application'

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-05-29MITREInternal CWE Team
+ View Metrics
CWEs in this viewTotal CWEs
Total19out of1006
Views0out of33
Categories0out of245
Weaknesses19out of720
Compound_Elements0out of8
View Components
View Components
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-312: Cleartext Storage of Sensitive Information

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

Description Summary

The application stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

Extended Description

Because the information is stored in cleartext, attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

+ Terminology Notes

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

An attacker with access to the system could read sensitive information stored in cleartext.

+ Demonstrative Examples

Example 1

The following code excerpt stores a plaintext user account ID in a browser cookie.

(Bad Code)
Example Language: Java 
response.addCookie( new Cookie("userAccountID", acctID);

Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.

Example 2

This code writes a user's login information to a cookie so the user does not have to login again later.

(Bad Code)
Example Language: PHP 
function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);
}

The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.

Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).

Example 3

The following code attempts to establish a connection, read in a password, then store it to a buffer.

(Bad Code)
Example Language:
server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host");
memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length);
if (argc < 3) port = 80;
else port = (unsigned short)atoi(argv[3]);
server.sin_port = htons(port);
if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting");
...
while ((n=read(sock,buffer,BUFSIZE-1))!=-1) {

write(dfd,password_buffer,n);
...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.

Example 4

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in plaintext.

This Java example shows a properties file with a plaintext username / password pair.

(Bad Code)
Example Language: Java 
# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in plaintext.

(Bad Code)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information and avoid CWE-260 and CWE-13.

+ Observed Examples
ReferenceDescription
password and username stored in cleartext in a cookie
password stored in cleartext in a file with insecure permissions
chat program disables SSL in some circumstances even when the user says to use SSL.
Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
storage of unencrypted passwords in a database
storage of unencrypted passwords in a database
product stores a password in cleartext in memory
storage of a secret key in cleartext in a temporary file
SCADA product uses HTTP Basic Authentication, which is not encrypted
login credentials stored unencrypted in a registry key
Plaintext credentials in world-readable file.
Password in cleartext in config file.
Password in cleartext in config file.
Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
Plaintext storage of private key and passphrase in log file when user imports the key.
Admin password in plaintext in a cookie.
Default configuration has cleartext usernames/passwords in cookie.
Usernames/passwords in cleartext in cookies.
Authentication information stored in cleartext in a cookie.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base311Missing Encryption of Sensitive Data
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfWeakness ClassWeakness Class922Insecure Storage of Sensitive Information
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant313Cleartext Storage in a File or on Disk
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant314Cleartext Storage in the Registry
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant315Cleartext Storage of Sensitive Information in a Cookie
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant316Cleartext Storage of Sensitive Information in Memory
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant317Cleartext Storage of Sensitive Information in GUI
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant318Cleartext Storage of Sensitive Information in Executable
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage of Sensitive Information
Software Fault PatternsSFP23Exposed Data
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft. 2002.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43.. 1st Edition. Addison Wesley. 2006.
[REF-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Description, Name
2010-02-16CWE Content TeamMITREInternal
updated References
2010-06-21CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITREInternal
updated Description, Relationships, Terminology_Notes
2014-07-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITREInternal
updated Related_Attack_Patterns
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Storage of Sensitive Information

CWE-319: Cleartext Transmission of Sensitive Information

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

Description Summary

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Extended Description

Many communication channels can be "sniffed" by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.

+ Time of Introduction
  • Architecture and Design
  • Operation
  • System Configuration
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Technical Impact: Read application data; Modify files or directories

Anyone can read the information by gaining access to the channel being used for communication.

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

+ Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(Bad Code)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();
}
catch (IOException e) {
//...
}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

+ Observed Examples
ReferenceDescription
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Potential Mitigations

Phase: Architecture and Design

Encrypt the data with a reliable encryption scheme before transmitting.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base311Missing Encryption of Sensitive Data
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory818OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2013)928
ChildOfCategoryCategory934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant5J2EE Misconfiguration: Data Transmission Without Encryption
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
CERT Java Secure CodingSER02-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
+ References
OWASP. "Top 10 2007-Insecure Communications". <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITREInternal
updated References
2010-04-05CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITREInternal
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITREInternal
updated Related_Attack_Patterns
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

CWE-250: Execution with Unnecessary Privileges

Weakness ID: 250
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

Extended Description

New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges.

Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges.

+ Time of Introduction
  • Installation
  • Architecture and Design
  • Operation
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Modes of Introduction

If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe.

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Gain privileges / assume identity; Execute unauthorized code or commands; Read application data; DoS: crash / exit / restart

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.

+ Likelihood of Exploit

Medium

+ Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and perform a login. Look for library functions and system calls that indicate when privileges are being raised or dropped. Look for accesses of resources that are restricted to normal users.

Note that this technique is only useful for privilege issues related to system resources. It is not likely to detect application-level business rules that are related to privileges, such as if a blog system allows a user to delete a blog entry without first checking that the user has administrator privileges.

Automated Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Compare binary / bytecode to application permission manifest

Cost effective for partial coverage:

  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis

  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR High

Manual Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Host-based Vulnerability Scanners – Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Host Application Interface Scanner

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Manual Source Code Review (not inspections)

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: SOAR High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Configuration Checker

  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Architecture / Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

  • Attack Modeling

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

This code temporarily raises the program's privileges to allow creation of a new user folder.

(Bad Code)
Example Language: Python 
def makeNewUserDir(username):
if invalidUsername(username):
#avoid CWE-22 and CWE-78
print('Usernames cannot contain invalid characters')
return False
try:
raisePrivileges()
os.mkdir('/home/' + username)
lowerPrivileges()
except OSError:
print('Unable to create new user directory for user:' + username)
return False
return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.

Example 2

The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.

(Bad Code)
Example Language:
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...

Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.

Example 3

This application intends to use a user's location to determine the timezone the user is in:

(Bad Code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
setTimeZone(userCurrLocation);

This is unnecessary use of the location API, as this information is already available using the Android Time API. Always be sure there is not another way to obtain needed information before resorting to using the location API.

Example 4

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(Bad Code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(Bad Code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

+ Observed Examples
ReferenceDescription
FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.
Program runs with privileges and calls another program with the same privileges, which allows read of arbitrary files.
OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.
Composite: application running with high privileges allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file.
Program does not drop privileges before calling another program, allowing code execution.
setuid root program allows creation of arbitrary files through command line argument.
Installation script installs some programs as setuid when they shouldn't be.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.250.2]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design

Strategies: Separation of Privilege; Identify and Reduce Attack Surface

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [R.250.2]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Implementation

Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.

Phase: Implementation

When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.

Phase: Implementation

If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [R.250.2]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.

Phases: Operation; System Configuration

Strategy: Environment Hardening

Ensure that the software runs properly under the Federal Desktop Core Configuration (FDCC) [R.250.4] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class227Improper Fulfillment of API Contract ('API Abuse')
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory265Privilege / Sandbox Issues
Development Concepts699
ChildOfWeakness BaseWeakness Base269Improper Privilege Management
Research Concepts1000
ChildOfWeakness ClassWeakness Class657Violation of Secure Design Principles
Development Concepts699
Research Concepts (primary)1000
ChildOfCategoryCategory7532009 Top 25 - Porous Defenses
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8662011 Top 25 - Porous Defenses
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory901SFP Primary Cluster: Privilege
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Relationship Notes

There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOften Misused: Privilege Management
CERT Java Secure CodingSER09-JMinimize privileges before deserializing from a privilege context
+ References
[R.250.1] Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. September, 1975. <http://web.mit.edu/Saltzer/www/publications/protection/>.
[R.250.2] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[R.250.3] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 7, "Running with Least Privilege" Page 207. 2nd Edition. Microsoft. 2002.
[R.250.4] [REF-24] NIST. "Federal Desktop Core Configuration". <http://nvd.nist.gov/fdcc/index.cfm>.
[R.250.5] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.
[R.250.6] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Privilege Vulnerabilities", Page 477.. 1st Edition. Addison Wesley. 2006.
+ Maintenance Notes

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category. Both CWE-272 and CWE-250 are in active use by the community. The "least privilege" phrase has multiple interpretations.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Description, Modes_of_Introduction, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description, Maintenance_Notes
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITREInternal
updated Detection_Factors, Potential_Mitigations, References
2010-06-21CWE Content TeamMITREInternal
updated Detection_Factors, Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-07-17CWE Content TeamMITREInternal
updated Applicable_Platforms
2014-02-18CWE Content TeamMITREInternal
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Often Misused: Privilege Management
2009-01-12Design Principle Violation: Failure to Use Least Privilege

CWE-359: Exposure of Private Information ('Privacy Violation')

Weakness ID: 359
Abstraction: Class
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software does not properly prevent private data (such as credit card numbers) from being accessed by actors who either (1) are not explicitly authorized to access the data or (2) do not have the implicit consent of the people to which the data is related.

Extended Description

Mishandling private information, such as customer passwords or Social Security numbers, can compromise user privacy and is often illegal. An exposure of private information does not necessarily prevent the software from working properly, and in fact it might be intended by the developer, but it can still be undesirable (or explicitly prohibited by law) for the people who are associated with this private information.

Privacy violations may occur when:

  1. Private user information enters the program.

  2. The data is written to an external location, such as the console, file system, or network.

Private data can enter a program in a variety of ways:

  1. Directly from the user in the form of a password or personal information

  2. Accessed from a database or other data store by the application

  3. Indirectly from a partner or other third party

Some types of private information include:

  • Government identifiers, such as Social Security Numbers

  • Contact information, such as home addresses and telephone numbers

  • Geographic location - where the user is (or was)

  • Employment history

  • Financial data - such as credit card numbers, salary, bank accounts, and debts

  • Pictures, video, or audio

  • Behavioral patterns - such as web surfing history, when certain activities are performed, etc.

  • Relationships (and types of relationships) with others - family, friends, contacts, etc.

  • Communications - e-mail addresses, private e-mail messages, SMS text messages, chat logs, etc.

  • Health - medical conditions, insurance status, prescription records

  • Credentials, such as passwords, which can be used to access other information.

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations: - Safe Harbor Privacy Framework [R.359.2] - Gramm-Leach Bliley Act (GLBA) [R.359.3] - Health Insurance Portability and Accountability Act (HIPAA) [R.359.4] - California SB-1386 [R.359.5].

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

+ Alternate Terms
Privacy leak
Privacy leakage
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

+ Demonstrative Examples

Example 1

In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [R.359.1]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.

Example 2

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

(Bad Code)
Example Language: C# 
pass = GetPassword();
...
dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Example 3

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(Bad Code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(Bad Code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class200Information Exposure
Research Concepts (primary)1000
ChildOfCategoryCategory254Security Features
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory857CERT Java Secure Coding Section 12 - Input Output (FIO)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory975SFP Secondary Cluster: Architecture
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant202Exposure of Sensitive Data Through Data Queries
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPrivacy Violation
CERT Java Secure CodingFIO13-JDo not log sensitive information outside a trust boundary
+ References
[R.359.1] J. Oates. "AOL man pleads guilty to selling 92m email addies". The Register. 2005. <http://www.theregister.co.uk/2005/02/07/aol_email_theft/>.
NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)". April 2010. <http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf>.
[R.359.2] [REF-2] U.S. Department of Commerce. "Safe Harbor Privacy Framework". <http://www.export.gov/safeharbor/>.
[R.359.3] [REF-3] Federal Trade Commission. "Financial Privacy: The Gramm-Leach Bliley Act (GLBA)". <http://www.ftc.gov/privacy/glbact/index.html>.
[R.359.4] [REF-4] U.S. Department of Human Services. "Health Insurance Portability and Accountability Act (HIPAA)". <http://www.hhs.gov/ocr/hipaa/>.
[R.359.5] [REF-5] Government of the State of California. "California SB-1386". 2002. <http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html>.
[R.359.6] [REF-1] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>.
[REF-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Other_Notes
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITREInternal
updated Other_Notes, References
2010-02-16CWE Content TeamMITREInternal
updated Other_Notes, References
2011-03-29CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITREInternal
updated Other_Notes, References
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, References
2014-02-18CWE Content TeamMITREInternal
updated Alternate_Terms, Demonstrative_Examples, Description, Name, Other_Notes, References
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2014-02-18Privacy Violation

CWE-939: Improper Authorization in Handler for Custom URL Scheme

Weakness ID: 939
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software uses a handler for a custom URL scheme, but it does not properly restrict which actors can invoke the handler using the scheme.

Extended Description

Mobile platforms and other architectures allow the use of custom URL schemes to facilitate communication between applications. In the case of iOS, this is the only method to do inter-application communication. The implementation is at the developer's discretion which may open security flaws in the application. An example could be potentially dangerous functionality such as modifying files through a custom URL scheme.

+ Applicable Platforms

Architectural Paradigms

Mobile Application

+ Demonstrative Examples

Example 1

This iOS application uses a custom URL scheme. The replaceFileText action in the URL scheme allows an external application to interface with the file incomingMessage.txt and replace the contents with the text field of the query string.

External Application

(Good Code)
Example Language: Objective-C 
NSString *stringURL = @"appscheme://replaceFileText?file=incomingMessage.txt&text=hello";
NSURL *url = [NSURL URLWithString:stringURL];
[[UIApplication sharedApplication] openURL:url];

Application URL Handler

(Bad Code)
 

- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
if (!url) {
return NO;
}
NSString *action = [url host];
if([action isEqualToString: @"replaceFileText"]) {
NSDictionary *dict = [self parseQueryStringExampleFunction:[url query]];
//this function will write contents to a specified file
FileObject *objectFile = [self writeToFile:[dict objectForKey: @"file"] withText:[dict objectForKey: @"text"]];
}
return YES;
}

The handler has no restriction on who can use its functionality. The handler can be invoked using any method that invokes the URL handler such as the following malicious iframe embedded on a web page opened by Safari.

(Attack)
Example Language: HTML 
<iframe src="appscheme://replaceFileText?file=Bookmarks.dat&text=listOfMaliciousWebsites">

The attacker can host a malicious website containing the iframe and trick users into going to the site via a crafted phishing email. Since Safari automatically executes iframes, the user is not prompted when the handler executes the iframe code which automatically invokes the URL handler replacing the bookmarks file with a list of malicious websites. Since replaceFileText is a potentially dangerous action, an action that modifies data, there should be a sanity check before the writeToFile:withText: function.

Example 2

These Android and iOS applications intercept URL loading and perform special actions if a particular URL scheme is used, thus allowing the Javascript within the WebView to communicate with the application:

(Bad Code)
Example Language: Java 
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url){
if (url.substring(0,14).equalsIgnoreCase("examplescheme:")){
if(url.substring(14,25).equalsIgnoreCase("getUserInfo")){
writeDataToView(view, UserData);
return false;
}
else{
return true;
}
}
}
(Bad Code)
Example Language: Objective-C 
-(BOOL) webView:(UIWebView *)exWebView shouldStartLoadWithRequest:(NSURLRequest *)exRequest navigationType:(UIWebViewNavigationType)exNavigationType
{
NSURL *URL = [exRequest URL];
if ([[URL scheme] isEqualToString:@"exampleScheme"])
{
NSString *functionString = [URL resourceSpecifier];
if ([functionString hasPrefix:@"specialFunction"])
{
// Make data available back in webview.
UIWebView *webView = [self writeDataToView:[URL query]];
}
return NO;
}
return YES;
}

A call into native code can then be initiated by passing parameters within the URL:

(Attack)
Example Language: Javascript 
window.location = examplescheme://method?parameter=value

Because the application does not check the source, a malicious website loaded within this WebView has the same access to the API as a trusted site.

+ Observed Examples
ReferenceDescription
URL scheme has action replace which requires no user prompt and allows remote attackers to perform undesired actions.
URL scheme has action follow and favorite which allows remote attackers to force user to perform undesired actions.
+ Potential Mitigations

Phase: Architecture and Design

Utilize a user prompt pop-up to authorize potentially harmful actions such as those modifying data or dealing with sensitive information.

When designing functionality of actions in the URL scheme, consider whether the action should be accessible to all mobile applications, or if a whitelist of applications to interface with is appropriate.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class862Missing Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
+ References
Guillaume Ross. "Scheming for Privacy and Security". 2013-11-11. <http://brooksreview.net/2013/11/guest-post_scheming-for-privacy-and-security/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2014-01-14MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-295: Improper Certificate Validation

Weakness ID: 295
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software does not validate, or incorrectly validates, a certificate.

Extended Description

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.

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

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Integrity
Authentication

Technical Impact: Bypass protection mechanism; Gain privileges / assume identity

+ Detection Methods

Automated Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis

  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Web Application Scanner

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Man-in-the-middle attack tool

Effectiveness: SOAR High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: SOAR High

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing man-in-the-middle attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle')).
Verification function trusts certificate chains in which the last certificate is self-signed.
Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA)
Web browser does not check if any intermediate certificates are revoked.
Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
Mobile banking application does not verify hostname, leading to financial loss.
Cloud-support library written in Python uses incorrect regular expression when matching hostname.
Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
Smartphone device does not verify hostname, allowing spoofing of mail services.
Application uses third-party library that does not validate hostname.
Cloud storage management application does not validate hostname.
Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
chain: incorrect calculation allows attackers to bypass certificate checks.
LDAP client accepts certificates even if they are not from a trusted CA.
chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
chain: product checks if client is trusted when it intended to check if the server is trusted, allowing validation of signed code.
Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
chain: OS package manager does not check properly check the return value, allowing bypass using a revoked certificate.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

+ Background Details

A certificate is a token that associates an identity (principle) to a cryptographic key. Certificates can be used to check if a public key belongs to the assumed owner.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory310Cryptographic Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
PeerOfWeakness BaseWeakness Base322Key Exchange without Entity Authentication
Research Concepts1000
ParentOfWeakness BaseWeakness Base296Improper Following of a Certificate's Chain of Trust
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant297Improper Validation of Certificate with Host Mismatch
Development Concepts (primary)699
Research Concepts1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant298Improper Validation of Certificate Expiration
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant299Improper Check for Certificate Revocation
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant599Missing Validation of OpenSSL Certificate
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
+ References
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security". 2012-10-16. <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.
M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Background_Details, Description
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2012-12-28
(Critical)
CWE Content TeamMITREInternal
Converted from category to weakness class.
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2013-02-21Certificate Issues

CWE-926: Improper Export of Android Application Components

Weakness ID: 926
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The Android application exports a component for use by other applications, but does not properly restrict which applications can launch the component or access the data it contains.

Extended Description

The attacks and consequences of improperly exporting a component may depend on the exported component:

  • If access to an exported Activity is not restricted, any application will be able to launch the activity. This may allow a malicious application to gain access to sensitive information, modify the internal state of the application, or trick a user into interacting with the victim application while believing they are still interacting with the malicious application.

  • If access to an exported Service is not restricted, any application may start and bind to the Service. Depending on the exposed functionality, this may allow a malicious application to perform unauthorized actions, gain access to sensitive information, or corrupt the internal state of the application.

  • If access to a Content Provider is not restricted to only the expected applications, then malicious applications might be able to access the sensitive data. Note that in Android before 4.2, the Content Provider is automatically exported unless it has been explicitly declared as NOT exported.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Availability
Integrity

Technical Impact: Unexpected state; DoS: crash / exit / restart; DoS: instability; Varies by context

Other applications, possibly untrusted, can launch the Activity.

Availability
Integrity

Technical Impact: Unexpected state; Gain privileges / assume identity; DoS: crash / exit / restart; DoS: instability; Varies by context

Other applications, possibly untrusted, can bind to the Service.

Confidentiality
Integrity

Technical Impact: Read application data; Modify application data

Other applications, possibly untrusted, can read or modify the data that is offered by the Content Provider.

+ Demonstrative Examples

Example 1

This application is exporting an activity and a service in its manifest.xml:

(Bad Code)
Example Language: XML 
<activity android:name="com.example.vulnerableApp.mainScreen">
...
<intent-filter>
<action android:name="com.example.vulnerableApp.OPEN_UI" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
...
</activity>
<service android:name="com.example.vulnerableApp.backgroundService">
...
<intent-filter>
<action android:name="com.example.vulnerableApp.START_BACKGROUND" />
</intent-filter>
...
</service>

Because these components have intent filters but have not explicitly set 'android:exported=false' elsewhere in the manifest, they are automatically exported so that any other application can launch them. This may lead to unintended behavior or exploits.

Example 2

This application has created a content provider to enable custom search suggestions within the application:

(Bad Code)
Example Language: XML 
<provider>
android:name="com.example.vulnerableApp.searchDB"
android:authorities="com.example.vulnerableApp.searchDB">
</provider>

Because this content provider is only intended to be used within the application, it does not need to be exported. However, in Android before 4.2, it is automatically exported thus potentially allowing malicious applications to access sensitive information.

+ Potential Mitigations

Phase: Build and Compilation

Strategy: Identify and Reduce Attack Surface

If they do not need to be shared by other applications, explicitly mark components with android:exported="false" in the application manifest.

Phase: Build and Compilation

Strategy: Identify and Reduce Attack Surface

If you only intend to use exported components between related apps under your control, use android:protectionLevel="signature" in the xml manifest to restrict access to applications signed by you.

Phases: Build and Compilation; Architecture and Design

Strategies: Identify and Reduce Attack Surface; Separation of Privilege

Limit Content Provider permissions (read/write) as appropriate.

+ Background Details

There are three types of components that can be exported in an Android application.

Activity

An Activity is an application component that provides a UI for users to interact with. A typical application will have multiple Activity screens that perform different functions, such as a main Activity screen and a separate settings Activity screen.

Service

A Service is an application component that is started by another component to execute an operation in the background, even after the invoking component is terminated. Services do not have a UI component visible to the user.

Content Provider

The Content Provider mechanism can be used to share data with other applications or internally within the same application.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class285Improper Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
+ References
[REF-34] Android Open Source Project. "Security Tips". 2013-07-16. <http://developer.android.com/training/articles/security-tips.html#ContentProviders>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-07-02MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2014-01-22
(Critical)
CWE Content TeamMITREInternal
Expanded entry to be more general and include all types of Android components that may be improperly exported.
2014-02-18CWE Content TeamMITREInternal
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Name, Potential_Mitigations, References
Previous Entry Names
Change DatePrevious Entry Name
2014-02-18Improper Restriction of Content Provider Export to Other Applications

CWE-920: Improper Restriction of Power Consumption

Weakness ID: 920
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software operates in an environment in which power is a limited resource that cannot be automatically replenished, but the software does not properly restrict the amount of power that its operation consumes.

Extended Description

In environments such as embedded or mobile devices, power can be a limited resource such as a battery, which cannot be automatically replenished by the software itself, and the device might not always be directly attached to a reliable power source. If the software uses too much power too quickly, then this could cause the device (and subsequently, the software) to stop functioning until power is restored, or increase the financial burden on the device owner because of increased power costs.

Normal operation of an application will consume power. However, in some cases, an attacker could cause the application to consume more power than intended, using components such as:

  • Display

  • CPU

  • Disk I/O

  • GPS

  • Sound

  • Microphone

  • USB interface

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (other); DoS: crash / exit / restart

The power source could be drained, causing the application - and the entire device - to cease functioning.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Development Concepts (primary)699
Research Concepts (primary)1000
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-06-11MITREInternal CWE Team

CWE-297: Improper Validation of Certificate with Host Mismatch

Weakness ID: 297
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software communicates with a host that provides a certificate, but the software does not properly ensure that the certificate is actually associated with that host.

Extended Description

Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the software is interacting with. If the certificate's host-specific data is not properly checked - such as the Common Name (CN) in the Subject or the Subject Alternative Name (SAN) extension of an X.509 certificate - it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host. In order to ensure data integrity, the certificate must be valid and it must pertain to the site that is being accessed.

Even if the software attempts to check the hostname, it is still possible to incorrectly check the hostname. For example, attackers could create a certificate with a name that begins with a trusted name followed by a NUL byte, which could cause some string-based comparisons to only examine the portion that contains the trusted name.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Gain privileges / assume identity

The data read from the system vouched for by the certificate may not be from the expected system.

Authentication
Other

Technical Impact: Other

Trust afforded to the system in question -- based on the expired certificate -- may allow for spoofing or redirection attacks.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

The following OpenSSL code obtains a certificate and verifies it.

(Bad Code)
Example Languages: C and C++ 
cert = SSL_get_peer_certificate(ssl);
if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) {
// do secret things
}

Even though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.

+ Observed Examples
ReferenceDescription
Mobile banking application does not verify hostname, leading to financial loss.
Mobile application for printing documents does not verify hostname, allowing attackers to read sensitive documents.
Software for electronic checking does not verify hostname, leading to financial loss.
Cloud-support library written in Python uses incorrect regular expression when matching hostname.
Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
Database program truncates the Common Name during hostname verification, allowing spoofing.
Incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
Mail server's incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
LDAP server's incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
Payment processing module does not verify hostname when connecting to PayPal using PHP fsockopen function.
Smartphone device does not verify hostname, allowing spoofing of mail services.
E-commerce module does not verify hostname when connecting to payment site.
Chat application does not validate hostname, leading to loss of privacy.
Application uses third-party library that does not validate hostname.
Cloud storage management application does not validate hostname.
Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
SOAP platform does not verify the hostname.
PHP library for payments does not verify the hostname.
Merchant SDK for payments does not verify the hostname.
Web browser does not validate Common Name, allowing spoofing of https sites.
+ Potential Mitigations

Phase: Architecture and Design

Check for expired certificates and provide the user with adequate information about the nature of the problem and how to proceed.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base295Improper Certificate Validation
Development Concepts (primary)699
Research Concepts1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Research Concepts (primary)1000
ChildOfCategoryCategory948SFP Secondary Cluster: Digital Certificate
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base370Missing Check for Certificate Revocation after Initial Check
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to validate host-specific certificate data
+ References
Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software". 2012-10-25. <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security". 2012-10-16. <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.
Kenneth Ballard. "Secure programming with the OpenSSL API, Part 2: Secure handshake". 2005-05-03. <http://www.ibm.com/developerworks/library/l-openssl2/index.html>.
Eric Rescorla. "An Introduction to OpenSSL Programming (Part I)". 2001-10-05. <http://www.rtfm.com/openssl-examples/part1.pdf>.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, References, Relationships, Type
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Validate Host-specific Certificate Data
2013-02-21Improper Validation of Host-specific Certificate Data

CWE-925: Improper Verification of Intent by Broadcast Receiver

Weakness ID: 925
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The Android application uses a Broadcast Receiver that receives an Intent but does not properly verify that the Intent came from an authorized source.

Extended Description

Certain types of Intents, identified by action string, can only be broadcast by the operating system itself, not by third-party applications. However, when an application registers to receive these implicit system intents, it is also registered to receive any explicit intents. While a malicious application cannot send an implicit system intent, it can send an explicit intent to the target application, which may assume that any received intent is a valid implicit system intent and not an explicit intent from another application. This may lead to unintended behavior.

+ Alternate Terms
Intent Spoofing
+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Gain privileges / assume identity

Another application can impersonate the operating system and cause the software to perform an unintended action.

+ Demonstrative Examples

Example 1

(Bad Code)
Example Language: XML 
<manifest package="com.example.vulnerableApplication">
<application>
...
<receiver android:name=".ShutdownReceiver">
<intent-filter>
<action android:name="android.intent.action.ACTION_SHUTDOWN" />
</intent-filter>
</receiver>
...
</application>
</manifest>

The ShutdownReceiver class will handle the intent:

(Bad Code)
Example Language: Java 
...
IntentFilter filter = new IntentFilter(Intent.ACTION_SHUTDOWN);
BroadcastReceiver sReceiver = new ShutDownReceiver();
registerReceiver(sReceiver, filter);
...
public class ShutdownReceiver extends BroadcastReceiver {
@Override
public void onReceive(final Context context, final Intent intent) {
mainActivity.saveLocalData();
mainActivity.stopActivity();
}
}

Because the method does not confirm that the intent action is the expected system intent, any received intent will trigger the shutdown procedure, as shown here:

(Attack)
Example Language: Java 
window.location = examplescheme://method?parameter=value

An attacker can use this behavior to cause a denial of service.

+ Potential Mitigations

Phase: Architecture and Design

Before acting on the Intent, check the Intent Action to make sure it matches the expected System action.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Development Concepts (primary)699
Research Concepts (primary)1000
+ References
[REF-35] Erika Chin, Adrienne Porter Felt, Kate Greenwood and David Wagner. "Analyzing Inter-Application Communication in Android". 3.2.1. <http://www.eecs.berkeley.edu/~daw/papers/intents-mobisys11.pdf>.
+ Maintenance Notes

This entry will be made more comprehensive in later CWE versions.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-06-24MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2014-02-18CWE Content TeamMITREInternal
updated Alternate_Terms, Demonstrative_Examples, Description, References

CWE-940: Improper Verification of Source of a Communication Channel

Weakness ID: 940
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.

Extended Description

When an attacker can successfully establish a communication channel from an untrusted origin, the attacker may be able to gain privileges and access unexpected functionality.

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

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Access Control
Other

Technical Impact: Gain privileges / assume identity; Varies by context

An attacker can access any functionality that is inadvertently accessible to the source.

+ Demonstrative Examples

Example 1

This Android application will remove a user account when it receives an intent to do so:

(Bad Code)
Example Language: Java 
IntentFilter filter = new IntentFilter("com.example.RemoveUser");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);

public class DeleteReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
int userID = intent.getIntExtra("userID");
destroyUserData(userID);
}
}

This application does not check the origin of the intent, thus allowing any malicious application to remove a user. Always check the origin of an intent, or create a whitelist of trusted applications using the manifest.xml file.

Example 2

These Android and iOS applications intercept URL loading within a WebView and perform special actions if a particular URL scheme is used, thus allowing the Javascript within the WebView to communicate with the application:

(Bad Code)
Example Language: Java 
// Android

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url){
if (url.substring(0,14).equalsIgnoreCase("examplescheme:")){
if(url.substring(14,25).equalsIgnoreCase("getUserInfo")){
writeDataToView(view, UserData);
return false;
}
else{
return true;
}
}
}
(Bad Code)
Example Language: Objective-C 
// iOS

-(BOOL) webView:(UIWebView *)exWebView shouldStartLoadWithRequest:(NSURLRequest *)exRequest navigationType:(UIWebViewNavigationType)exNavigationType
{
NSURL *URL = [exRequest URL];
if ([[URL scheme] isEqualToString:@"exampleScheme"])
{
NSString *functionString = [URL resourceSpecifier];
if ([functionString hasPrefix:@"specialFunction"])
{
// Make data available back in webview.
UIWebView *webView = [self writeDataToView:[URL query]];
}
return NO;
}
return YES;
}

A call into native code can then be initiated by passing parameters within the URL:

(Attack)
Example Language: Javascript 
window.location = examplescheme://method?parameter=value

Because the application does not check the source, a malicious website loaded within this WebView has the same access to the API as a trusted site.

+ Observed Examples
ReferenceDescription
DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
DNS server caches glue records received from non-delegated name servers
+ Potential Mitigations

Phase: Architecture and Design

Use a mechanism that can validate the identity of the source, such as a certificate, and validate the integrity of data to ensure that it cannot be modified in transit using a man-in-the-middle attack.

When designing functionality of actions in the URL scheme, consider whether the action should be accessible to all mobile applications, or if a whitelist of applications to interface with is appropriate.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Development Concepts (primary)699
Research Concepts (primary)1000
+ Relationship Notes

While many access control issues involve authenticating the user, this weakness is more about authenticating the actual source of the communication channel itself; there might not be any "user" in such cases.

+ References
Taimur Aslam. "A Taxonomy of Security Faults in the UNIX Operating System". 1995-08-01. <http://cwe.mitre.org/documents/sources/ATaxonomyofSecurityFaultsintheUNIXOperatingSystem%5BAslam95%5D.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2014-02-13MITREInternal CWE Team

CWE-941: Incorrectly Specified Destination in a Communication Channel

Weakness ID: 941
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software creates a communication channel to initiate an outgoing request to an actor, but it does not correctly specify the intended destination for that actor.

Extended Description

Attackers at the destination may be able to spoof trusted servers to steal data or cause a denial of service.

There are at least two distinct weaknesses that can cause the software to communicate with an unintended destination:

  • If the software allows an attacker to control which destination is specified, then the attacker can cause it to connect to an untrusted or malicious destination. For example, because UDP is a connectionless protocol, UDP packets can be spoofed by specifying a false source address in the packet; when the server receives the packet and sends a reply, it will specify a destination by using the source of the incoming packet - i.e., the false source. The server can then be tricked into sending traffic to the wrong host, which is effective for hiding the real source of an attack and for conducting a distributed denial of service (DDoS). As another example, server-side request forgery (SSRF) and XML External Entity (XXE) can be used to trick a server into making outgoing requests to hosts that cannot be directly accessed by the attacker due to firewall restrictions.

  • If the software incorrectly specifies the destination, then an attacker who can control this destination might be able to spoof trusted servers. While the most common occurrence is likely due to misconfiguration by an administrator, this can be resultant from other weaknesses. For example, the software might incorrectly parse an e-mail or IP address and send sensitive data to an unintended destination. As another example, an Android application may use a "sticky broadcast" to communicate with a receiver for a particular application, but since sticky broadcasts can be processed by *any* receiver, this can allow a malicious application to access restricted data that was only intended for a different application.

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

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Demonstrative Examples

Example 1

This code listens on a port for DNS requests and sends the result to the requesting address.

(Bad Code)
Example Language: Python 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) )
while true:
data = sock.recvfrom(1024)
if not data:
break
(requestIP, nameToResolve) = parseUDPpacket(data)
record = resolveName(nameToResolve)
sendResponse(requestIP,record)

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.

+ Observed Examples
ReferenceDescription
composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
DNS query with spoofed source address causes more traffic to be returned to spoofed address than was sent by the attacker.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Development Concepts (primary)699
Research Concepts (primary)1000
CanPrecedeWeakness BaseWeakness Base406Insufficient Control of Network Message Volume (Network Amplification)
Research Concepts1000
+ References
US-CERT. "UDP-based Amplification Attacks". 2014-01-17. <https://www.us-cert.gov/ncas/alerts/TA14-017A>.
+ Maintenance Notes

This entry will be made more comprehensive in later CWE versions.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2014-02-13MITREInternal CWE Team

CWE-200: Information Exposure

Weakness ID: 200
Abstraction: Class
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

An information exposure is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information.

Extended Description

The information either

  1. is regarded as sensitive within the product's own functionality, such as a private message; or

  2. provides information about the product or its environment that could be useful in an attack but is normally not available to the attacker, such as the installation path of a product that is remotely accessible.

Many information exposures are resultant (e.g. PHP script error revealing the full path of the program), but they can also be primary (e.g. timing discrepancies in cryptography). There are many different types of problems that involve information exposures. Their severity can range widely depending on the type of information that is revealed.

+ Alternate Terms
Information Leak:

This is a frequently used term, however the "leak" term has multiple uses within security. In some cases it deals with exposure of information, but in other cases (such as "memory leak") this deals with improper tracking of resources which can lead to exhaustion. As a result, CWE is actively avoiding usage of the "leak" term.

Information Disclosure:

This term is frequently used in vulnerability databases and other sources, however "disclosure" does not always have security implications. The phrase "information disclosure" is also used frequently in policies and legal documents, but do not refer to disclosure of security-relevant information.

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

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

+ Likelihood of Exploit

High

+ Detection Methods

Automated Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis

  • Inter-application Flow Analysis

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR High

Dynamic Analysis with manual results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Fuzz Tester

  • Framework-based Fuzzer

  • Automated Monitored Execution

  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Context-configured Source Code Weakness Analyzer

Cost effective for partial coverage:

  • Source code Weakness Analyzer

Effectiveness: SOAR High

Architecture / Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

  • Attack Modeling

  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: SOAR High

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory199Information Management Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory840Business Logic Errors
Development Concepts699
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant201Information Exposure Through Sent Data
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant202Exposure of Sensitive Data Through Data Queries
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class203Information Exposure Through Discrepancy
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base209Information Exposure Through an Error Message
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base212Improper Cross-boundary Removal of Sensitive Data
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base213Intentional Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant214Information Exposure Through Process Environment
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant215Information Exposure Through Debug Information
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base226Sensitive Information Uncleared Before Release
Development Concepts (primary)699
Research Concepts1000
ParentOfWeakness ClassWeakness Class359Exposure of Private Information ('Privacy Violation')
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant497Exposure of System Data to an Unauthorized Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant524Information Exposure Through Caching
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant526Information Exposure Through Environmental Variables
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base538File and Directory Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant598Information Exposure Through Query Strings in GET Request
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant612Information Exposure Through Indexing of Private Data
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
CanFollowWeakness VariantWeakness Variant498Cloneable Class Containing Sensitive Information
Development Concepts699
Research Concepts1000
CanFollowWeakness VariantWeakness Variant499Serializable Class Containing Sensitive Data
Development Concepts699
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInformation Leak (information disclosure)
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
WASC13Information Leakage
+ References
[REF-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-12-28CWE Content TeamMITREInternal
updated Alternate_Terms, Description, Name
2010-02-16CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITREInternal
updated Description, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, References
2014-06-23CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Related_Attack_Patterns
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak (Information Disclosure)

CWE-511: Logic/Time Bomb

Weakness ID: 511
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software contains code that is designed to disrupt the legitimate operation of the software (or its environment) when a certain time passes, or when a certain logical condition is met.

Extended Description

When the time bomb or logic bomb is detonated, it may perform a denial of service such as crashing the system, deleting critical data, or degrading system response time. This bomb might be placed within either a replicating or non-replicating Trojan horse.

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

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Other
Integrity

Technical Impact: Varies by context; Alter execution logic

+ Demonstrative Examples

Example 1

Typical examples of triggers include system date or time mechanisms, random number generators, and counters that wait for an opportunity to launch their payload. When triggered, a time-bomb may deny service by crashing the system, deleting files, or degrading system response-time.

+ Potential Mitigations

Phase: Installation

Always verify the integrity of the software that is being installed.

Phase: Testing

Conduct a code coverage analysis using live testing, then closely inspect any code that is not covered.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class506Embedded Malicious Code
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory904SFP Primary Cluster: Malware
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrLogic/Time Bomb
+ References
[REF-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
LandwehrExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, Potential_Mitigations, References, Time_of_Introduction

CWE-772: Missing Release of Resource after Effective Lifetime

Weakness ID: 772
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.

Extended Description

When a resource is not released after use, it can allow attackers to cause a denial of service.

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

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (other)

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.

+ Likelihood of Exploit

Medium to High

+ Demonstrative Examples

Example 1

The following code attempts to process a file by reading it in line by line until the end has been reached.

(Bad Code)
Example Language: Java 
private void processFile(string fName)
{
BufferReader in = new BufferReader(new FileReader(fName));
String line;
while ((line = in.ReadLine()) != null)
{
processLine(line);
}
}

The problem with the above code is that it never closes the file handle it opens. The Finalize() method for BufferReader eventually calls Close(), but there is no guarantee as to how long it will take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in the VM using up all of its available file handles.

Example 2

The following code attempts to open a new connection to a database, process the results returned by the database, and close the allocated SqlConnection object.

(Bad Code)
Example Language: C# 
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();

The problem with the above code is that if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

Example 3

The following method never closes the file handle it opens. The Finalize() method for StreamReader eventually calls Close(), but there is no guarantee as to how long it will take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in the VM using up all of its available file handles.

(Bad Code)
Example Language: Java 
private void processFile(string fName) {
StreamWriter sw = new StreamWriter(fName);
string line;
while ((line = sr.ReadLine()) != null){
processLine(line);
}
}

Example 4

This code attempts to open a connection to a database and catches any exceptions that may occur.

(Bad Code)
Example Language: Java 
try {
Connection con = DriverManager.getConnection(some_connection_string);
}
catch ( Exception e ) {
log( e );
}

If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application.

Example 5

Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

(Bad Code)
Example Language: C# 
...
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();
...

Example 6

The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.

(Bad Code)
Example Language:
int decodeFile(char* fName) {
char buf[BUF_SZ];
FILE* f = fopen(fName, "r");
if (!f) {
printf("cannot open %s\n", fName);
return DECODE_FAIL;
}
else {
while (fgets(buf, BUF_SZ, f)) {
if (!checkChecksum(buf)) {
return DECODE_FAIL;
}
else {
decodeBlock(buf);
}
}
}
fclose(f);
return DECODE_SUCCESS;
}
+ Observed Examples
ReferenceDescription
Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.
Sockets not properly closed when attacker repeatedly connects and disconnects from server.
Does not shut down named pipe connections if malformed data is sent.
Chain: memory leak (CWE-404) leads to resource exhaustion.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Port scan triggers CPU consumption with processes that attempt to read data from closed sockets.
Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake.
Return values of file/socket operations not checked, allowing resultant consumption of file descriptors.
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.

Phase: Implementation

It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.

Phases: Operation; Architecture and Design

Strategy: Limit Resource Consumption

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Research Concepts1000
ChildOfWeakness BaseWeakness Base404Improper Resource Shutdown or Release
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory882CERT C++ Secure Coding Section 14 - Concurrency (CON)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory982SFP Secondary Cluster: Failure to Release Resource
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base401Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant775Missing Release of File Descriptor or Handle after Effective Lifetime
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base911Improper Update of Reference Count
Research Concepts1000
+ Theoretical Notes

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C++ Secure CodingCON02-CPPUse lock classes for mutex management
Software Fault PatternsSFP14Failure to release resource
+ Maintenance Notes

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-05-13Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2010-02-16CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Observed_Examples, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-672: Operation on a Resource after Expiration or Release

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

Description Summary

The software uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Technical Impact: Modify application data; Read application data

If a released resource is subsequently reused or reallocated, then an attempt to use the original resource might allow access to sensitive data that is associated with a different user or entity.

Other
Availability

Technical Impact: Other; DoS: crash / exit / restart

When a resource is released it might not be in an expected state, later attempts to access the resource may lead to resultant errors that may lead to a crash.

+ Demonstrative Examples

Example 1

The following code shows a simple example of a use after free error:

(Bad Code)
Example Language:
char* ptr = (char*)malloc (SIZE);
if (err) {
abrt = 1;
free(ptr);
}
...
if (abrt) {
logError("operation aborted before commit", ptr);
}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

Example 2

The following code shows a simple example of a double free error:

(Bad Code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances

  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 3

In the following C/C++ example the method processMessage is used to process a message received in the input array of char arrays. The input message array contains two char arrays: the first is the length of the message and the second is the body of the message. The length of the message is retrieved and used to allocate enough memory for a local char array, messageBody, to be created for the message body. The messageBody is processed in the method processMessageBody that will return an error if an error occurs while processing. If an error occurs then the return result variable is set to indicate an error and the messageBody char array memory is released using the method free and an error message is sent to the logError method.

(Bad Code)
Example Languages: C and C++ 
#define FAIL 0
#define SUCCESS 1
#define ERROR -1
#define MAX_MESSAGE_SIZE 32

int processMessage(char **message)
{
int result = SUCCESS;

int length = getMessageLength(message[0]);
char *messageBody;

if ((length > 0) && (length < MAX_MESSAGE_SIZE)) {

messageBody = (char*)malloc(length*sizeof(char));
messageBody = &message[1][0];

int success = processMessageBody(messageBody);

if (success == ERROR) {
result = ERROR;
free(messageBody);
}
}
else {
printf("Unable to process message; invalid message length");
result = FAIL;
}

if (result == ERROR) {
logError("Error processing message", messageBody);
}

return result;
}

However, the call to the method logError includes the messageBody after the memory for messageBody has been released using the free method. This can cause unexpected results and may lead to system crashes. A variable should never be used after its memory resources have been released.

(Good Code)
Example Languages: C and C++ 
...
messageBody = (char*)malloc(length*sizeof(char));
messageBody = &message[1][0];

int success = processMessageBody(messageBody);

if (success == ERROR) {
result = ERROR;
logError("Error processing message", messageBody);
free(messageBody);
}
...
+ Observed Examples
ReferenceDescription
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base666Operation on Resource in Wrong Phase of Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory983SFP Secondary Cluster: Faulty Resource Use
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant298Improper Validation of Certificate Expiration
Research Concepts1000
ParentOfWeakness BaseWeakness Base324Use of a Key Past its Expiration Date
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base562Return of Stack Variable Address
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base613Insufficient Session Expiration
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base825Expired Pointer Dereference
Development Concepts699
Research Concepts1000
ParentOfWeakness BaseWeakness Base910Use of Expired File Descriptor
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base826Premature Release of Resource During Expected Lifetime
Research Concepts1000
CanFollowWeakness BaseWeakness Base911Improper Update of Reference Count
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP15Faulty Resource Use
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Name, Relationships
2010-09-27CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Relationships
2013-02-21CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Applicable_Platforms
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Use of a Resource after Expiration or Release

CWE-921: Storage of Sensitive Data in a Mechanism without Access Control

Weakness ID: 921
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software stores sensitive information in a file system or device that does not have built-in access control.

Extended Description

While many modern file systems or devices utilize some form of access control in order to restrict access to data, not all storage mechanisms have this capability. For example, memory cards, floppy disks, CDs, and USB devices are typically made accessible to any user within the system. This can become a problem when sensitive data is stored in these mechanisms in a multi-user environment, because anybody on the system can read or write this data.

On Android devices, external storage is typically globally readable and writable by other applications on the device. External storage may also be easily accessible through the mobile device's USB connection or physically accessible through the device's memory card port.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data; Read files or directories

Attackers can read sensitive information by accessing the unrestricted storage mechanism.

Integrity

Technical Impact: Modify application data; Modify files or directories

Attackers can modify or delete sensitive information by accessing the unrestricted storage mechanism.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class922Insecure Storage of Sensitive Information
Development Concepts (primary)699
Research Concepts (primary)1000
+ References
Android Open Source Project. "Security Tips". 2013-07-16. <http://developer.android.com/training/articles/security-tips.html#StoringData>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-06-22MITREInternal CWE Team

CWE-798: Use of Hard-coded Credentials

Weakness ID: 798
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.

Extended Description

Hard-coded credentials typically create a significant hole that allows an attacker to bypass the authentication that has been configured by the software administrator. This hole might be difficult for the system administrator to detect. Even if detected, it can be difficult to fix, so the administrator may be forced into disabling the product entirely. There are two main variations:

Inbound: the software contains an authentication mechanism that checks the input credentials against a hard-coded set of credentials.

Outbound: the software connects to another system or component, and it contains hard-coded credentials for connecting to that component.

In the Inbound variant, a default administration account is created, and a simple password is hard-coded into the product and associated with that account. This hard-coded password is the same for each installation of the product, and it usually cannot be changed or disabled by system administrators without manually modifying the program, or otherwise patching the software. If the password is ever discovered or published (a common occurrence on the Internet), then anybody with knowledge of this password can access the product. Finally, since all installations of the software will have the same password, even across different organizations, this enables massive attacks such as worms to take place.

The Outbound variant applies to front-end systems that authenticate with a back-end service. The back-end service may require a fixed password which can be easily discovered. The programmer may simply hard-code those back-end credentials into the front-end software. Any user of that program may be able to extract the password. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question.

Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Read application data; Gain privileges / assume identity; Execute unauthorized code or commands; Other

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.

+ Likelihood of Exploit

Very High

+ Detection Methods

Black Box

Credential storage in configuration files is findable using black box methods, but the use of hard-coded credentials for an incoming authentication routine typically involves an account that is not visible outside of the code.

Effectiveness: Moderate

Automated Static Analysis

Automated white box techniques have been published for detecting hard-coded credentials for incoming authentication, but there is some expert disagreement regarding their effectiveness and applicability to a broad range of methods.

Manual Static Analysis

This weakness may be detectable using manual code analysis. Unless authentication is decentralized and applied throughout the software, there can be sufficient time for the analyst to find incoming authentication routines and examine the program logic looking for usage of hard-coded credentials. Configuration files could also be analyzed.

These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Manual Dynamic Analysis

For hard-coded credentials in incoming authentication: use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and perform a login. Using call trees or similar artifacts from the output, examine the associated behaviors and see if any of them appear to be comparing the input to a fixed string or value.

Automated Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis

  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR High

Dynamic Analysis with manual results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Network Sniffer

  • Forced Path Execution

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR High

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Configuration Checker

Effectiveness: SOAR Partial

Architecture / Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

  • Formal Methods / Correct-By-Construction

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

The following code uses a hard-coded password to connect to a database:

(Bad Code)
Example Language: Java 
...
DriverManager.getConnection(url, "scott", "tiger");
...

This is an example of an external hard-coded password on the client-side of a connection. This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:

(Attack)
 
javap -c ConnMngr.class
22: ldc #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc #38; //String scott
26: ldc #17; //String tiger

Example 2

The following code is an example of an internal hard-coded password in the back-end:

(Bad Code)
Example Languages: C and C++ 
int VerifyAdmin(char *password) {
if (strcmp(password, "Mew!")) {

printf("Incorrect Password!\n");
return(0)
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(Bad Code)
Example Language: Java 
int VerifyAdmin(String password) {
if (passwd.Equals("Mew!")) {
return(0)
}
//Diagnostic Mode
return(1);
}

Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."

Example 3

The following code examples attempt to verify a password using a hard-coded cryptographic key.

(Bad Code)
Example Languages: C and C++ 
int VerifyAdmin(char *password) {
if (strcmp(password,"68af404b513073584c4b6f22b6c63e6b")) {

printf("Incorrect Password!\n");
return(0);
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(Bad Code)
Example Language: Java 
public boolean VerifyAdmin(String password) {
if (password.equals("68af404b513073584c4b6f22b6c63e6b")) {
System.out.println("Entering Diagnostic Mode...");
return true;
}
System.out.println("Incorrect Password!");
return false;
(Bad Code)
Example Language: C# 
int VerifyAdmin(String password) {
if (password.Equals("68af404b513073584c4b6f22b6c63e6b")) {
Console.WriteLine("Entering Diagnostic Mode...");
return(1);
}
Console.WriteLine("Incorrect Password!");
return(0);
}

The cryptographic key is within a hard-coded string value that is compared to the password. It is likely that an attacker will be able to read the key and compromise the system.

Example 4

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in plaintext.

This Java example shows a properties file with a plaintext username / password pair.

(Bad Code)
Example Language: Java 
# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in plaintext.

(Bad Code)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information and avoid CWE-260 and CWE-13.

+ Observed Examples
ReferenceDescription
SCADA system uses a hard-coded password to protect back-end database containing authorization information, exploited by Stuxnet worm
FTP server library uses hard-coded usernames and passwords for three default accounts
Chain: Router firmware uses hard-coded username and password for access to debug functionality, which can be used to execute arbitrary code
Server uses hard-coded authentication key
Backup product uses hard-coded username and password, allowing attackers to bypass authentication via the RPC interface
Security appliance uses hard-coded password allowing attackers to gain root access
Drive encryption product stores hard-coded cryptographic keys for encrypted configuration files in executable programs
VoIP product uses unchangeable hard-coded public credentials that cannot be changed, which allows attackers to obtain sensitive information
VoIP product uses hard coded public and private SNMP community strings that cannot be changed, which allows remote attackers to obtain sensitive information
Backup product contains hard-coded credentials that effectively serve as a back door, which allows remote attackers to access the file system
+ Potential Mitigations

Phase: Architecture and Design

For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible [R.798.1].

In Windows environments, the Encrypted File System (EFS) may provide some protection.

Phase: Architecture and Design

For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key.

Phase: Architecture and Design

If the software must contain hard-coded credentials or they cannot be removed, perform access control checks and limit which entities can access the feature that requires the hard-coded credentials. For example, a feature might only be enabled through the system console instead of through a network connection.

Phase: Architecture and Design

For inbound authentication using passwords: apply strong one-way hashes to passwords and store those hashes in a configuration file or database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the password. When handling an incoming password during authentication, take the hash of the password and compare it to the saved hash.

Use randomly assigned salts for each separate hash that is generated. This increases the amount of computation that an attacker needs to conduct a brute-force attack, possibly limiting the effectiveness of the rainbow table method.

Phase: Architecture and Design

For front-end to back-end connections: Three solutions are possible, although none are complete.

  • The first suggestion involves the use of generated passwords or keys that are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.

  • Next, the passwords or keys should be limited at the back end to only performing actions valid for the front end, as opposed to having full access.

  • Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay-style attacks.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory255Credentials Management
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class287Improper Authentication
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base344Use of Invariant Value in Dynamically Changing Context
Research Concepts1000
ChildOfWeakness ClassWeakness Class671Lack of Administrator Control over Security
Research Concepts1000
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory7532009 Top 25 - Porous Defenses
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8032010 Top 25 - Porous Defenses
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory812OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory861CERT Java Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8662011 Top 25 - Porous Defenses
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
PeerOfWeakness BaseWeakness Base257Storing Passwords in a Recoverable Format
Research Concepts1000
ParentOfWeakness BaseWeakness Base259Use of Hard-coded Password
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base321Use of Hard-coded Cryptographic Key
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingMSC03-JNever hard code sensitive information
+ References
[R.798.1] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 8, "Key Management Issues" Page 272. 2nd Edition. Microsoft. 2002.
[R.798.2] Johannes Ullrich. "Top 25 Series - Rank 11 - Hardcoded Credentials". SANS Software Security Institute. 2010-03-10. <http://blogs.sans.org/appsecstreetfighter/2010/03/10/top-25-series-rank-11-hardcoded-credentials/>.
[REF-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2010-01-15MITREInternal CWE Team
More abstract entry for hard-coded password and hard-coded cryptographic key.
Modifications
Modification DateModifierOrganizationSource
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, References
2014-07-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Related_Attack_Patterns

CWE-927: Use of Implicit Intent for Sensitive Communication

Weakness ID: 927
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The Android application uses an implicit intent for transmitting sensitive data to other applications.

Extended Description

Since an implicit intent does not specify a particular application to receive the data, any application can process the intent by using an Intent Filter for that intent. This can allow untrusted applications to obtain sensitive data. There are two variations on the standard broadcast intent, ordered and sticky.

Ordered broadcast intents are delivered to a series of registered receivers in order of priority as declared by the Receivers. A malicious receiver can give itself a high priority and cause a denial of service by stopping the broadcast from propagating further down the chain. There is also the possibility of malicious data modification, as a receiver may also alter the data within the Intent before passing it on to the next receiver. The downstream components have no way of asserting that the data has not been altered earlier in the chain.

Sticky broadcast intents remain accessible after the initial broadcast. An old sticky intent will be broadcast again to any new receivers that register for it in the future, greatly increasing the chances of information exposure over time. Also, sticky broadcasts cannot be protected by permissions that may apply to other kinds of intents.

In addition, any broadcast intent may include a URI that references data that the receiving component does not normally have the privileges to access. The sender of the intent can include special privileges that grant the receiver read or write access to the specific URI included in the intent. A malicious receiver that intercepts this intent will also gain those privileges and be able to read or write the resource at the specified URI.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

Other applications, possibly untrusted, can read the data that is offered through the Intent.

Integrity

Technical Impact: Varies by context

The application may handle responses from untrusted applications on the device, which could cause it to perform unexpected or unauthorized actions.

+ Demonstrative Examples

Example 1

This application wants to create a user account in several trusted applications using one broadcast intent:

(Bad Code)
Example Language: Java 
Intent intent = new Intent();
intent.setAction("com.example.CreateUser");
intent.putExtra("Username", uname_string);
intent.putExtra("Password", pw_string);
sendBroadcast(intent);

This application assumes only the trusted applications will be listening for the action. A malicious application can register for this action and intercept the user's login information, as below:

(Attack)
Example Language: Java 
IntentFilter filter = new IntentFilter("com.example.CreateUser");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);

When a broadcast contains sensitive information, create a whitelist of applications that can receive the action using the application's manifest file, or programmatically send the intent to each individual intended receiver.

Example 2

This application interfaces with a web service that requires a separate user login. It creates a sticky intent, so that future trusted applications that also use the web service will know who the current user is:

(Bad Code)
Example Language: Java 
Intent intent = new Intent();
intent.setAction("com.example.service.UserExists");
intent.putExtra("Username", uname_string);
sendStickyBroadcast(intent);
(Attack)
Example Language: Java 
IntentFilter filter = new IntentFilter("com.example.service.UserExists");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);

Sticky broadcasts can be read by any application at any time, and so should never contain sensitive information such as a username.

Example 3

This application is sending an ordered broadcast, asking other applications to open a URL:

(Bad Code)
Example Language: Java 
Intent intent = new Intent();
intent.setAction("com.example.OpenURL");
intent.putExtra("URL_TO_OPEN", url_string);
sendOrderedBroadcastAsUser(intent);

Any application in the broadcast chain may alter the data within the intent. This malicious application is altering the URL to point to an attack site:

(Attack)
Example Language: Java 
public class CallReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
String Url = intent.getStringExtra(Intent.URL_TO_OPEN);
attackURL = "www.example.com/attack?" + Url;
setResultData(attackURL);
}
}

The final receiving application will then open the attack URL. Where possible, send intents to specific trusted applications instead of using a broadcast chain.

Example 4

This application sends a special intent with a flag that allows the receiving application to read a data file for backup purposes.

(Bad Code)
Example Language: Java 
Intent intent = new Intent();
intent.setAction("com.example.BackupUserData");
intent.setData(file_uri);
intent.addFlags(FLAG_GRANT_READ_URI_PERMISSION);
sendBroadcast(intent);
(Attack)
Example Language: Java 
public class CallReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Uri userData = intent.getData();
stealUserData(userData);
}
}

Any malicious application can register to receive this intent. Because of the FLAG_GRANT_READ_URI_PERMISSION included with the intent, the malicious receiver code can read the user's data.

+ Potential Mitigations

Phase: Implementation

If the application only requires communication with its own components, then the destination is always known, and an explicit intent could be used.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class285Improper Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts1000
+ References
[REF-35] Erika Chin, Adrienne Porter Felt, Kate Greenwood and David Wagner. "Analyzing Inter-Application Communication in Android". 3.2.1. <http://www.eecs.berkeley.edu/~daw/papers/intents-mobisys11.pdf>.
[REF-34] Android Open Source Project. "Security Tips". 2013-07-16. <http://developer.android.com/training/articles/security-tips.html#ContentProviders>.
+ Maintenance Notes

This entry will be made more comprehensive in later CWE versions.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-07-09MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2014-02-18CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, References

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