Kingdom: Code Quality

Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an attacker it provides an opportunity to stress the system in unexpected ways.

94 items found
Weaknesses
Abstract
An implicit PendingIntent has been detected. Implicit pending intents might result in security vulnerabilities such as denial of service, private and system information leakage, and privilege escalation.
Explanation
Android Intents are used to bind applications and application components together by providing instruction on actions that a given component performs. Pending intents are created to deliver the Intent at a later time. Implicit intents facilitate the calling of intents from any given external component, using a general name and filter to determine execution.

When an implicit Intent is created as a PendingIntent, this might allow for the Intent to be sent to an unintended component that runs outside of the intended temporal context, leaving the system vulnerable to exploit vectors such as denial of service, private and system information leakage, and privilege escalation.

Example 1: The following code uses an implicit PendingIntent.


...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
this,
0,
imp_intent,
flag_mut
)
...
References
[1] Remediation for Implicit PendingIntent Vulnerability
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_implicit_pending_intent
Abstract
A PendingIntent has been detected that has its flag value set to FLAG_MUTABLE. Pending intents created with the flag value of FLAG_MUTABLE are susceptible to having unspecified Intent fields set downstream, which can modify the capacity of the Intent and leave the system open to vulnerability.
Explanation
Allowing modification of the underlying Intent of a PendingIntent after its creation can leave a system open to attack. This mostly depends on the overall capability of the underlying Intent. In most cases, it is best practice to prevent potential issues by setting the PendingIntent flag to FLAG_IMMUTABLE.

Example 1: The following includes a PendingIntent created with a flag value of FLAG_MUTABLE.


...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
References
[1] Remediation for Implicit PendingIntent Vulnerability
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_mutable_pending_intent
Abstract
Memory is allocated but never freed.
Explanation
Memory leaks 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.

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker may be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].

Example 1: The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes:


char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.controlflow.cpp.memory_leak
Abstract
Memory is allocated but never freed.
Explanation
Memory leaks 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.

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].

Example 1: The following Micro Focus COBOL program leaks a block of allocated memory if an error occurs:


CALL "CBL_ALLOC_MEM"
USING mem-pointer
BY VALUE mem-size
BY VALUE flags
RETURNING status-code
END-CALL

IF status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
SET ADDRESS OF mem TO mem-pointer
END-IF

PERFORM write-data
IF ws-status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
DISPLAY "Success!"
END-IF

CALL "CBL_FREE_MEM"
USING BY VALUE mem-pointer
RETURNING status-code
END-CALL

GOBACK
.
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.controlflow.cobol.memory_leak
Abstract
An object allocates memory for a member variable and fails to free it in its dealloc() method.
Explanation
Memory leaks 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.

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker may be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].

Example 1: The Objective-C object allocates memory in the init() method but fails to free it in the deallocate() method, resulting in a memory leak:


- (void)init
{
myVar = [NSString alloc] init];
...
}

- (void)dealloc
{
[otherVar release];
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.structural.objc.memory_leak
Abstract
The program resizes a block of allocated memory. If the resize fails, the original block will be leaked.
Explanation
Memory leaks 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.

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker may be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].

Example 1: The following C function leaks a block of allocated memory if the call to realloc() fails to resize the original allocation.


char* getBlocks(int fd) {
int amt;
int request = BLOCK_SIZE;
char* buf = (char*) malloc(BLOCK_SIZE + 1);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
while ((amt % BLOCK_SIZE) != 0) {
if (amt < request) {
goto ERR;
}
request = request + BLOCK_SIZE;
buf = realloc(buf, request);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
}

return buf;

ERR:
if (buf) {
free(buf);
}
return NULL;
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 401
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.memory_leak_reallocation
Abstract
The program resizes a block of allocated memory. If the resize fails, the original block will be leaked.
Explanation
Memory leaks 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.

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].

Example 1: The following Micro Focus COBOL program leaks a block of allocated memory if the call to realloc() fails to resize the original allocation.


CALL "malloc" USING
BY VALUE mem-size
RETURNING mem-pointer
END-CALL

ADD 1000 TO mem-size

CALL "realloc" USING
BY VALUE mem-pointer
BY VALUE mem-size
RETURNING mem-pointer
END-CALL

IF mem-pointer <> null
CALL "free" USING
BY VALUE mem-pointer
END-CALL
END-IF
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 401
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cobol.memory_leak_reallocation
Abstract
The program can potentially dereference a null-pointer, thereby raising a NullException.
Explanation
Null-pointer errors are usually the result of one or more programmer assumptions being violated.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null-pointer exception when it attempts to call the Trim() method.


string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
desc.controlflow.dotnet.null_dereference
Abstract
The program can potentially dereference a null-pointer, thereby causing a segmentation fault.
Explanation
Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the variable ptr is not NULL. That assumption is made explicit when the programmer dereferences the pointer. This assumption is later contradicted when the programmer checks ptr against NULL. If ptr can be NULL when it is checked in the if statement then it can also be NULL when it dereferenced and may cause a segmentation fault.


ptr->field = val;
...
if (ptr != NULL) {
...
}
Example 2: In the following code, the programmer confirms that the variable ptr is NULL and subsequently dereferences it erroneously. If ptr is NULL when it is checked in the if statement, then a null dereference will occur, thereby causing a segmentation fault.


if (ptr == null) {
ptr->field = val;
...
}
Example 3: In the following code, the programmer forgets that the string '\0' is actually 0 or NULL, thereby dereferencing a null-pointer and causing a segmentation fault.


if (ptr == '\0') {
*ptr = val;
...
}
Example 4: In the following code, the programmer explicitly sets the variable ptr to NULL. Later, the programmer dereferences ptr before checking the object for a null value.


*ptr = NULL;
...
ptr->field = val;
...
}
desc.controlflow.cpp.null_dereference
Abstract
The program can potentially dereference a null-pointer, thereby raising a NullPointerException.
Explanation
Null-pointer errors are usually the result of one or more programmer assumptions being violated.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example: In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null-pointer exception when it attempts to call the trim() method.


String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
desc.controlflow.java.null_dereference
Abstract
The use of deprecated or obsolete functions could indicate neglected code.
Explanation
In general as programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Statements that are removed from a language are usually replaced by newer counterparts that perform the same task in somewhat different and hopefully better way.

In particular, SAP ABAP evolved to include ABAP Objects - the object oriented extension of ABAP and to operate in a Unicode compatible environment. As a result, stricter syntax is enforced in classes or in Unicode programs. Obsolete constructs are still available only for reasons of compatibility with older releases and they can only be used outside of classes or in non-Unicode programs. There are replacement constructions for all obsolete language elements, which improve the efficiency and readability of programs. Many implicit, ambiguous type/length/memory specifications in the obsolete syntax are required to be specified in a more precise and explicit way in the newer syntax. It is recommended to adopt the newer syntax to make programs easier to understand, more robust and easier to maintain.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.
desc.semantic.abap.obsolete
Abstract
The use of deprecated or obsolete functions could indicate neglected code.
Explanation
As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations


Functions that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example: The following code constructs a new SqlClientPermission object, which regulates how users are allowed to connect to a database. In this example, the program passes false as the second parameter to the constructor, which controls whether users are allowed to connect with blank passwords. Passing false to this parameter indicates that blank passwords should not be allowed.


...
SCP = new SqlClientPermission(pstate, false);
...


However, because the PermissionState object passed as the first parameter supersedes any value passed to the second parameter, the constructor allows blank passwords for database connections, which contradicts the second argument. To disallow blank passwords, the program should pass PermissionState.None to the first parameter of the constructor. Because of the ambiguity in its functionality, the two-parameter version of the SqlClientPermission constructor has been deprecated in favor of the single parameter version, which conveys the same degree of information without the risk of misinterpretation.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.
desc.semantic.dotnet.obsolete
Abstract
The use of deprecated or obsolete functions could indicate neglected code.
Explanation
As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language.
- Improved understanding of how operations should be performed effectively and securely.
- Changes in the conventions that govern certain operations.

Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.
Example: The following code uses the deprecated function getpw() to verify that a plain text password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0.


...
getpw(uid, pwdline);
for (i=0; i<3; i++){
cryptpw=strtok(pwdline, ":");
pwdline=0;
}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...


Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.
desc.semantic.cpp.obsolete
Abstract
The use of deprecated or obsolete functions could indicate neglected code or the use of an antiquated version of ColdFusion.
Explanation
As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.
desc.semantic.cfml.obsolete
Abstract
The use of deprecated or obsolete functions could indicate neglected code.
Explanation
As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example: The following code constructs a string object from an array of bytes and a value that specifies the top 8 bits of each 16-bit Unicode character.


...
String name = new String(nameBytes, highByte);
...


In this example, the constructor may fail to correctly convert bytes to characters depending on which charset is used to encode the string represented by nameBytes. Due to the evolution of the charsets used to encode strings, this constructor was deprecated and replaced by a constructor that accepts as one of its parameters the name of the charset used to encode the bytes for conversion.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.
References
[1] MET02-J. Do not use deprecated or obsolete classes or methods CERT
desc.semantic.java.obsolete
Abstract
The use of deprecated or obsolete functions could indicate neglected code.
Explanation
As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations.

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example: The following code uses the Digest::HMAC stdlib, which use of is explicitly discouraged in the documentation due to accidental involvement within a release.


require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...


In this example the Digest::HMAC class was deprecated immediately upon involvement due to accidental inclusion within a release. Due to possibility of this not working as expected because of experimental and not properly tested code, use of this is highly discouraged, especially considering the relation HMACs have in relation to cryptographic functionality.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.
desc.structural.ruby.obsolete
Abstract
A deprecated function is used.
Explanation
Due to the fast-paced nature of smart contracts, functions and operators may become deprecated with newer compiler versions and using them may lead to low quality code, unintended side effects and/or compilation errors.

Example 1: The following code obtains the hash of the current block using block.blockhash(), which has been deprecated since version 0.5.0 of the Solidity compiler.


bytes32 blockhash = block.blockhash(0);
desc.structural.solidity.swc111
Abstract
The function is obsolete and cannot guarantee that a pointer is valid or referenced memory is safe to use.
Explanation
There are a number of reasons not to use the IsBadXXXPtr() class of functions. These functions are:
1) Not thread safe.
2) Often implicated in crashes caused by their probing of invalid memory addresses.
3) Erroneously believed to carry out proper error handling during exception conditions.

Example: The following code uses IsBadWritePtr() in an attempt to prevent bad memory writes.

if (IsBadWritePtr(ptr, length))
{
[handle error]
}


Programmers often use these functions intending that they will detect exception cases, but the functions usually cause more problems than they fix.
References
[1] Raymond Chen IsBadXxxPtr should really be called CrashProgramRandomly
[2] IsBadWritePtr Function Microsoft
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 730
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[11] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[13] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[34] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[35] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.cpp.obsolete_inadequate_pointer_validation