Krutikp/ComplianceLLM huggingface dataset:
CWE-764: Multiple Locks of a Critical Resource (Base)

Description: The product locks a critical resource more times than intended, leading to an unexpected state in the system.

Extended Description: When a product is operating in a concurrent environment and repeatedly locks a critical resource, the consequences will vary based on the type of lock, the lock's implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra locking calls will reduce the size of the total available pool, possibly leading to degraded performance or a denial of service. If this can be triggered by an attacker, it will be similar to an unrestricted lock (CWE-412). In the context of a binary lock, it is likely that any duplicate locking attempts will never succeed since the lock is already held and progress may not be possible.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:SCOPE:Integrity:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Unexpected State::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.::




Notes: ::TYPE:Maintenance:NOTE:An alternate way to think about this weakness is as an imbalance between the number of locks / unlocks in the control flow. Over the course of execution, if each lock call is not followed by a subsequent call to unlock in a reasonable amount of time, then system performance may be degraded or at least operating at less than peak levels if there is competition for the locks. This entry may need to be modified to reflect these concepts in the future.::
CWE-765: Multiple Unlocks of a Critical Resource (Base)

Description: The product unlocks a critical resource more times than intended, leading to an unexpected state in the system.

Extended Description: When the product is operating in a concurrent environment and repeatedly unlocks a critical resource, the consequences will vary based on the type of lock, the lock's implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra calls to unlock will increase the count for the number of available resources, likely resulting in a crash or unpredictable behavior when the system nears capacity.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:SCOPE:Integrity:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Modify Memory:IMPACT:Unexpected State::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the product acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.::

Observed Examples: ::REFERENCE:CVE-2009-0935:DESCRIPTION:Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0935::



Notes: ::TYPE:Maintenance:NOTE:An alternate way to think about this weakness is as an imbalance between the number of locks / unlocks in the control flow. Over the course of execution, if each lock call is not followed by a subsequent call to unlock in a reasonable amount of time, then system performance may be degraded or at least operating at less than peak levels if there is competition for the locks. This entry may need to be modified to reflect these concepts in the future.::
CWE-766: Critical Data Element Declared Public (Base)

Description: The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

Extended Description: This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.



Applicable Platforms: ::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C#:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Integrity:SCOPE:Confidentiality:IMPACT:Read Application Data:IMPACT:Modify Application Data:NOTE:Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.::SCOPE:Other:IMPACT:Reduce Maintainability::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.::

Observed Examples: ::REFERENCE:CVE-2010-3860:DESCRIPTION:variables declared public allow remote read of system properties such as user name and home directory.:LINK:https://www.cve.org/CVERecord?id=CVE-2010-3860::
CWE-767: Access to Critical Private Variable via Public Method (Base)

Description: The product defines a public method that reads or modifies a private variable.

Extended Description: If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.



Applicable Platforms: ::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C#:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Integrity:SCOPE:Other:IMPACT:Modify Application Data:IMPACT:Other::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data.::




Notes: ::TYPE:Maintenance:NOTE:This entry is closely associated with access control for public methods. If the public methods are restricted with proper access controls, then the information in the private variable will not be exposed to unexpected parties. There may be chaining or composite relationships between improper access controls and this weakness.::
CWE-771: Missing Reference to Active Allocated Resource (Base)

Description: The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.

Extended Description: This does not necessarily apply in languages or frameworks that automatically perform garbage collection, since the removal of all references may act as a signal that the resource is ready to be reclaimed.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Resource Consumption (Other):NOTE:An attacker that can influence the allocation of resources that are not properly maintained could deplete the available resource pool and prevent all other processes from accessing the same type of resource.::


Potential Mitigations: ::PHASE:Operation Architecture and Design:STRATEGY:Resource Limitation:DESCRIPTION: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).::
CWE-776: Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') (Base)

Description: The product uses XML documents and allows their structure to be defined with a Document Type Definition (DTD), but it does not properly control the number of recursive definitions of entities.

Extended Description: If the DTD contains a large number of nested or recursive entities, this can lead to explosive growth of data when parsed, causing a denial of service.


Alternate Terms: ::TERM:XEE:DESCRIPTION:XEE is the acronym commonly used for XML Entity Expansion.::TERM:Billion Laughs Attack::TERM:XML Bomb:DESCRIPTION:While the XML Bomb term was used in the early years of knowledge of this issue, the XEE term seems to be more commonly used.::

Applicable Platforms: ::LANGUAGE NAME:XML:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::PHASE:Operation::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Resource Consumption (Other):NOTE:If parsed, recursive entity references allow the attacker to expand data exponentially, quickly consuming all system resources.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Operation:DESCRIPTION:If possible, prohibit the use of DTDs or use an XML parser that limits the expansion of recursive DTD entities.::PHASE:Implementation:DESCRIPTION:Before parsing XML files with associated DTDs, scan for recursive entity declarations and do not continue parsing potentially explosive content.::

Observed Examples: ::REFERENCE:CVE-2008-3281:DESCRIPTION:XEE in XML-parsing library.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3281::REFERENCE:CVE-2011-3288:DESCRIPTION:XML bomb / XEE in enterprise communication product.:LINK:https://www.cve.org/CVERecord?id=CVE-2011-3288::REFERENCE:CVE-2011-1755:DESCRIPTION:Billion laughs attack in XMPP server daemon.:LINK:https://www.cve.org/CVERecord?id=CVE-2011-1755::REFERENCE:CVE-2009-1955:DESCRIPTION:XML bomb in web server module:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1955::REFERENCE:CVE-2003-1564:DESCRIPTION:Parsing library allows XML bomb:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1564::
CWE-779: Logging of Excessive Data (Base)

Description: The product logs too much information, making log files hard to process and possibly hindering recovery efforts or forensic analysis after an attack.

Extended Description: While logging is a good practice in general, and very high levels of logging are appropriate for debugging stages of development, too much logging in a production environment might hinder a system administrator's ability to detect anomalous conditions. This can provide cover for an attacker while attempting to penetrate a system, clutter the audit trail for forensic analysis, or make it more difficult to debug problems in a production environment.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Operation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Other):NOTE:Log files can become so large that they consume excessive resources, such as disk and CPU, which can hinder the performance of the system.::SCOPE:Non-Repudiation:IMPACT:Hide Activities:NOTE:Logging too much information can make the log files of less use to forensics analysts and developers when trying to diagnose a problem or recover from an attack.::SCOPE:Non-Repudiation:IMPACT:Hide Activities:NOTE:If system administrators are unable to effectively process log files, attempted attacks may go undetected, possibly leading to eventual system compromise.::


Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:Suppress large numbers of duplicate log messages and replace them with periodic summaries. For example, syslog may include an entry that states last message repeated X times when recording repeated events.::PHASE:Architecture and Design:DESCRIPTION:Support a maximum size for the log file that can be controlled by the administrator. If the maximum size is reached, the admin should be notified. Also, consider reducing functionality of the product. This may result in a denial-of-service to legitimate product users, but it will prevent the product from adversely impacting the entire system.::PHASE:Implementation:DESCRIPTION:Adjust configurations appropriately when the product is transitioned from a debug state to production.::

Observed Examples: ::REFERENCE:CVE-2007-0421:DESCRIPTION:server records a large amount of data to the server log when it receives malformed headers:LINK:https://www.cve.org/CVERecord?id=CVE-2007-0421::REFERENCE:CVE-2002-1154:DESCRIPTION:chain: application does not restrict access to front-end for updates, which allows attacker to fill the error log:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1154::
CWE-783: Operator Precedence Logic Error (Base)

Description: The product uses an expression in which operator precedence causes incorrect logic to be used.

Extended Description: While often just a bug, operator precedence logic errors can have serious consequences if they are used in security-critical code, such as making an authentication decision.



Applicable Platforms: ::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Rarely::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Rarely::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Rarely::

Modes of Introduction: ::PHASE:Implementation:NOTE:Logic errors related to operator precedence may cause problems even during normal operation, so they are probably discovered quickly during the testing phase. If testing is incomplete or there is a strong reliance on manual review of the code, then these errors may not be discovered before the software is deployed.::



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Varies by Context:IMPACT:Unexpected State:NOTE:The consequences will vary based on the context surrounding the incorrect precedence. In a security decision, integrity or confidentiality are the most likely results. Otherwise, a crash may occur due to the software reaching an unexpected state.::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Regularly wrap sub-expressions in parentheses, especially in security-critical code.::

Observed Examples: ::REFERENCE:CVE-2008-2516:DESCRIPTION:Authentication module allows authentication bypass because it uses (x = call(args) == SUCCESS) instead of ((x = call(args)) == SUCCESS).:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2516::REFERENCE:CVE-2008-0599:DESCRIPTION:Chain: Language interpreter calculates wrong buffer size (CWE-131) by using size = ptr ? X : Y instead of size = (ptr ? X : Y) expression.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0599::REFERENCE:CVE-2001-1155:DESCRIPTION:Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1155::
CWE-791: Incomplete Filtering of Special Elements (Base)

Description: The product receives data from an upstream component, but does not completely filter special elements before sending it to a downstream component.





Modes of Introduction: ::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::



Common Consequences: ::SCOPE:Integrity:IMPACT:Unexpected State::
CWE-804: Guessable CAPTCHA (Base)

Description: The product uses a CAPTCHA challenge, but the challenge can be guessed or automatically recognized by a non-human actor.

Extended Description: An automated attacker could bypass the intended protection of the CAPTCHA challenge and perform actions at a higher frequency than humanly possible, such as launching spam attacks. There can be several different causes of a guessable CAPTCHA: An audio or visual image that does not have sufficient distortion from the unobfuscated source image. A question is generated with a format that can be automatically recognized, such as a math question. A question for which the number of possible answers is limited, such as birth years or favorite sports teams. A general-knowledge or trivia question for which the answer can be accessed using a data base, such as country capitals or popular entertainers. Other data associated with the CAPTCHA may provide hints about its contents, such as an image whose filename contains the word that is used in the CAPTCHA.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY NAME:Web Server:TECHNOLOGY PREVALENCE:Sometimes::

Modes of Introduction: ::PHASE:Architecture and Design::PHASE:Implementation::



Common Consequences: ::SCOPE:Access Control:SCOPE:Other:IMPACT:Bypass Protection Mechanism:IMPACT:Other:NOTE:When authorization, authentication, or another protection mechanism relies on CAPTCHA entities to ensure that only human actors can access certain functionality, then an automated attacker such as a bot may access the restricted functionality by guessing the CAPTCHA.::



Observed Examples: ::REFERENCE:CVE-2022-4036:DESCRIPTION:Chain: appointment booking app uses a weak hash (CWE-328) for generating a CAPTCHA, making it guessable (CWE-804):LINK:https://www.cve.org/CVERecord?id=CVE-2022-4036::
CWE-820: Missing Synchronization (Base)

Description: The product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.

Extended Description: If access to a shared resource is not synchronized, then the resource may not be in a state that is expected by the product. This might lead to unexpected or insecure behaviors, especially if an attacker can influence the shared resource.







Common Consequences: ::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Other:IMPACT:Modify Application Data:IMPACT:Read Application Data:IMPACT:Alter Execution Logic::






Notes: ::TYPE:Maintenance:NOTE:Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.::
CWE-821: Incorrect Synchronization (Base)

Description: The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.

Extended Description: If access to a shared resource is not correctly synchronized, then the resource may not be in a state that is expected by the product. This might lead to unexpected or insecure behaviors, especially if an attacker can influence the shared resource.







Common Consequences: ::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Other:IMPACT:Modify Application Data:IMPACT:Read Application Data:IMPACT:Alter Execution Logic::






Notes: ::TYPE:Maintenance:NOTE:Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.::
CWE-826: Premature Release of Resource During Expected Lifetime (Base)

Description: The product releases a resource that is still intended to be used by itself or another actor.

Extended Description: This weakness focuses on errors in which the product should not release a resource, but performs the release anyway. This is different than a weakness in which the product releases a resource at the appropriate time, but it maintains a reference to the resource, which it later accesses. For this weakness, the resource should still be valid upon the subsequent access. When a product releases a resource that is still being used, it is possible that operations will still be taken on this resource, which may have been repurposed in the meantime, leading to issues similar to CWE-825. Consequences may include denial of service, information exposure, or code execution.







Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data:IMPACT:Read Memory:NOTE:If the released resource is subsequently reused or reallocated, then a read operation on the original resource might access sensitive data that is associated with a different user or entity.::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:NOTE:When the resource is released, the software might modify some of its structure, or close associated channels (such as a file descriptor). When the software later accesses the resource as if it is valid, the resource might not be in an expected state, leading to resultant errors that may lead to a crash.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Modify Application Data:IMPACT:Modify Memory:NOTE:When the resource is released, the software might modify some of its structure. This might affect logic in the sections of code that still assume the resource is active. If the released resource is related to memory and is used in a function call, or points to unexpected data in a write operation, then code execution may be possible upon subsequent accesses.::



Observed Examples: ::REFERENCE:CVE-2009-3547:DESCRIPTION:Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476):LINK:https://www.cve.org/CVERecord?id=CVE-2009-3547::



Notes: ::TYPE:Research Gap:NOTE:Under-studied and under-reported as of September 2010. This weakness has been reported in high-visibility software, although the focus has been primarily on memory allocation and de-allocation. There are very few examples of this weakness that are not directly related to memory management, although such weaknesses are likely to occur in real-world software for other types of resources.::