deardaniel/secdata-raw huggingface dataset:
CWE-385: Covert Timing Channel

Description:
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.

Extended Description:
In some instances, knowing when data is transmitted between parties can provide a malicious user with privileged information. Also, externally monitoring the timing of operations can potentially reveal sensitive data. For example, a cryptographic operation can expose its internal state if the time it takes to perform the operation varies, based on the state. 
             Covert channels are frequently classified as either storage or timing channels. Some examples of covert timing channels are the system's paging rate, the time a certain transaction requires to execute, and the time it takes to gain access to a shared bus.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-514

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Whenever possible, specify implementation strategies that do not introduce time variances in operations.
  - [Implementation] Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker.
  - [Implementation] It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application.

Demonstrative examples:
In this example, the attacker observes how long an authentication takes when the user types in the correct password.
When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.
def validate_password(actual_pw, typed_pw):
		  
                    if len(actual_pw) <> len(typed_pw):
		    return 0 
                    for i in len(actual_pw):
CWE-386: Symbolic Name not Mapping to Correct Object

Description:
A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-706

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Integrity: Modify Application Data
  - Integrity: Modify Application Data
  - Non-Repudiation: Hide Activities
  - Non-Repudiation: Modify Files or Directories
CWE-39: Path Traversal: 'C:dirname'

Description:
The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-36

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Integrity: Modify Files or Directories
  - Confidentiality: Read Files or Directories
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2001-0038: Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.
  - CVE-2001-0255: FTP server allows remote attackers to list arbitrary directories by using the "ls" command and including the drive letter name (e.g. C:) in the requested pathname.
  - CVE-2001-0687: FTP server allows a remote attacker to retrieve privileged system information by specifying arbitrary paths.
  - CVE-2001-0933: FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.
  - CVE-2002-0466: Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.
CWE-390: Detection of Error Condition Without Action

Description:
The product detects a specific error, but takes no actions to handle the error.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-755

Consequences:
  - Integrity: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.
  - [Implementation] If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.
  - [Testing] Subject the product to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.

Demonstrative examples:
The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.
The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed if (foo==NULL) { //We do nothing so we just ignore the error. }
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed if (foo==NULL) { printf("Malloc failed to allocate memory resources"); return -1; }

In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed.
The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue pro

Real-world examples:
  - CVE-2022-21820: A GPU data center manager detects an error due to a malformed request but does not act on it, leading to memory corruption.
CWE-391: Unchecked Error Condition

Description:
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-754, CWE-703, CWE-703

Consequences:
  - Integrity: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Requirements] The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.
  - [Requirements] A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.
  - [Implementation] Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Demonstrative examples:
The following code excerpt ignores a rarely-thrown exception from doExchange().
If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.
try { doExchange(); } catch (RareException e) { 
                         
                            
                            // this can never happen 
                            
                         
                      }
CWE-392: Missing Report of Error Condition

Description:
The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-755, CWE-684, CWE-703, CWE-703

Consequences:
  - Integrity: Varies by Context

Demonstrative examples:
In the following snippet from a doPost() servlet method, the server returns "200 OK" (default) even if an error occurs.

try { 
                         
                            
                            // Something that may throw an exception. 
                            ... 
                      } catch (Throwable t) { logger.error("Caught: " + t.toString()); return; }

Real-world examples:
  - CVE-2024-52316: Web-based product can throw an exception during authentication but does not report the failure in the HTTP status code, allowing authentication bypass.
  - [REF-1374]: Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generat
  - CVE-2004-0063: Function returns "OK" even if another function returns a different status code than expected, leading to accepting an invalid PIN number.
  - CVE-2002-1446: Error checking routine in PKCS#11 library returns "OK" status even when invalid signature is detected, allowing spoofed messages.
  - CVE-2002-0499: Kernel function truncates long pathnames without generating an error, leading to operation on wrong directory.
CWE-393: Return of Wrong Status Code

Description:
A function or operation returns an incorrect return value or status code that does not indicate the true result of execution, causing the product to modify its behavior based on the incorrect result.

Extended Description:
This can lead to unpredictable behavior. If the function is used to make security-critical decisions or provide security-critical information, then the wrong status code can cause the product to assume that an action is safe or correct, even when it is not.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-684, CWE-703

Consequences:
  - Integrity: Unexpected State

Detection methods:
  - Fuzzing: Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with rand

Demonstrative examples:
In the following example, an HTTP 404 status code is returned in the event of an IOException encountered in a Java servlet. A 404 code is typically meant to indicate a non-existent resource and would be somewhat misleading in this case.

try { 
                         
                            
                            // something that might throw IOException 
                            ... 
                      } catch (IOException ioe) { response.sendError(SC_NOT_FOUND); }

Real-world examples:
  - CVE-2003-1132: DNS server returns wrong response code for non-existent AAAA record, which effectively says that the domain is inaccessible.
  - CVE-2001-1509: Hardware-specific implementation of system call causes incorrect results from geteuid.
  - CVE-2001-1559: Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
  - CVE-2014-1266: Chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-56
CWE-394: Unexpected Status Code or Return Value

Description:
The product does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the product.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-754

Consequences:
  - Integrity: Unexpected State

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Real-world examples:
  - CVE-2004-1395: Certain packets (zero byte and other lengths) cause a recvfrom call to produce an unexpected return code that causes a server's listening loop to exit.
  - CVE-2002-2124: Unchecked return code from recv() leads to infinite loop.
  - CVE-2005-2553: Kernel function does not properly handle when a null is returned by a function call, causing it to call another function that it shouldn't.
  - CVE-2005-1858: Memory not properly cleared when read() function call returns fewer bytes than expected.
  - CVE-2000-0536: Bypass access restrictions when connecting from IP whose DNS reverse lookup does not return a hostname.
CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference

Description:
Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.

Extended Description:
Programmers typically catch NullPointerException under three circumstances: 
                
                   The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem. 
                   The program explicitly throws a NullPointerException to signal an error condition. 
                   The code is part of a test harness that supplies unexpected input to the classes under test. 
                
             Of these three circumstances, only the last is acceptable.

Affected languages: Java
Parent weaknesses: CWE-705, CWE-755

Consequences:
  - Availability: DoS: Resource Consumption (CPU)

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           

Mitigations:
  - [Architecture and Design] Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application.

Demonstrative examples:
The following code mistakenly catches a NullPointerException.

try {
				   
					mysteryMethod();
				   
				  } catch (NullPointerException npe) { 
                  }
CWE-396: Declaration of Catch for Generic Exception

Description:
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.

Extended Description:
Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of a language's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

Affected languages: C++, Java, C#, Python
Parent weaknesses: CWE-705, CWE-755, CWE-221

Consequences:
  - Non-Repudiation: Hide Activities

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Demonstrative examples:
The following code excerpt handles three types of exceptions in an identical fashion.
At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:
try { doExchange(); } catch (IOException e) { logger.error("doExchange failed", e); } catch (InvocationTargetException e) { 
                         
                            logger.error("doExchange failed", e); 
                      } catch (SQLException e) { 
                         
                            logger.error("doExchange failed", e); 
                      }
try { doExchange(); } catch (Exception e) { logger.error("doExchange failed", e); }
CWE-397: Declaration of Throws for Generic Exception

Description:
The product throws or raises an overly broad exceptions that can hide important details and produce inappropriate responses to certain conditions.

Extended Description:
Declaring a method to throw Exception or Throwable promotes generic error handling procedures that make it difficult for callers to perform proper error handling and error recovery. For example, Java's exception mechanism makes it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

Affected languages: C++, C#, Java, Python
Parent weaknesses: CWE-705, CWE-221, CWE-703

Consequences:
  - Non-Repudiation: Hide Activities

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Demonstrative examples:
The following method throws three types of exceptions.
While it might seem tidier to write
public void doExchange() throws IOException, InvocationTargetException, SQLException { ... }
public void doExchange() throws Exception { ... }

Early versions of C++ (C++98, C++03, C++11) included a feature known as Dynamic Exception Specification. This allowed functions to declare what type of exceptions it may throw. It is possible to declare a general class of exception to cover any derived exceptions that may be thrown.
In the example above, the code declares that myfunction() can throw an exception of type "std::exception" thus hiding details about the possible derived exceptions that could potentially be thrown.
int myfunction() throw(std::exception) { if (0) throw out_of_range(); throw length_error(); }
CWE-40: Path Traversal: '\\UNC\share\name\' (Windows UNC Share)

Description:
The product accepts input that identifies a Windows UNC share ('\\UNC\share\name') that potentially redirects access to an unintended location or arbitrary file.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-36

Consequences:
  - Confidentiality: Read Files or Directories

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2001-0687: FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (\\computername\sharename).