Krutikp/ComplianceLLM huggingface dataset:
CWE-270: Privilege Context Switching Error (Base)

Description: The product does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.




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

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



Common Consequences: ::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:A user can assume the identity of another user with separate privileges in another context. This will give the user unauthorized access that may allow them to acquire the access information of other users.::


Potential Mitigations: ::PHASE:Architecture and Design Operation:DESCRIPTION:Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. 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:STRATEGY:Separation of Privilege:DESCRIPTION:Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.::

Observed Examples: ::REFERENCE:CVE-2002-1688:DESCRIPTION:Web browser cross domain problem when user hits back button.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1688::REFERENCE:CVE-2003-1026:DESCRIPTION:Web browser cross domain problem when user hits back button.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1026::REFERENCE:CVE-2002-1770:DESCRIPTION:Cross-domain issue - third party product passes code to web browser, which executes it in unsafe zone.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1770::REFERENCE:CVE-2005-2263:DESCRIPTION:Run callback in different security context after it has been changed from untrusted to trusted. * note that context switch before actions are completed is one type of problem that happens frequently, espec. in browsers.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2263::



Notes: ::TYPE:Research Gap:NOTE:This concept needs more study.::
CWE-274: Improper Handling of Insufficient Privileges (Base)

Description: The product does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.




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

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



Common Consequences: ::SCOPE:Other:IMPACT:Other:IMPACT:Alter Execution Logic::

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::


Observed Examples: ::REFERENCE:CVE-2001-1564:DESCRIPTION:System limits are not properly enforced after privileges are dropped.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1564::REFERENCE:CVE-2005-3286:DESCRIPTION:Firewall crashes when it can't read a critical memory block that was protected by a malicious process.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3286::REFERENCE:CVE-2005-1641:DESCRIPTION:Does not give admin sufficient privileges to overcome otherwise legitimate user actions.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1641::



Notes: ::TYPE:Maintenance:NOTE:CWE-280 and CWE-274 are too similar. It is likely that CWE-274 will be deprecated in the future.::TYPE:Relationship:NOTE:Overlaps dropped privileges, insufficient permissions.::TYPE:Theoretical:NOTE:This has a layering relationship with Unchecked Error Condition and Unchecked Return Value.::TYPE:Theoretical:NOTE:Within the context of vulnerability theory, privileges and permissions are two sides of the same coin. Privileges are associated with actors, and permissions are associated with resources. To perform access control, at some point the product makes a decision about whether the actor (and the privileges that have been assigned to that actor) is allowed to access the resource (based on the permissions that have been specified for that resource).::
CWE-277: Insecure Inherited Permissions (Variant)

Description: A product defines a set of insecure permissions that are inherited by objects that are created by the program.




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

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



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::


Potential Mitigations: ::PHASE:Architecture and Design Operation:DESCRIPTION:Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION: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 the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::

Observed Examples: ::REFERENCE:CVE-2005-1841:DESCRIPTION:User's umask is used when creating temp files.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1841::REFERENCE:CVE-2002-1786:DESCRIPTION:Insecure umask for core dumps [is the umask preserved or assigned?].:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1786::
CWE-278: Insecure Preserved Inherited Permissions (Variant)

Description: A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement.




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

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



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::


Potential Mitigations: ::PHASE:Architecture and Design Operation:DESCRIPTION:Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION: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 the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::

Observed Examples: ::REFERENCE:CVE-2005-1724:DESCRIPTION:Does not obey specified permissions when exporting.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1724::
CWE-279: Incorrect Execution-Assigned Permissions (Variant)

Description: While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.




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

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



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::


Potential Mitigations: ::PHASE:Architecture and Design Operation:DESCRIPTION:Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION: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 the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::

Observed Examples: ::REFERENCE:CVE-2002-0265:DESCRIPTION:Log files opened read/write.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0265::REFERENCE:CVE-2003-0876:DESCRIPTION:Log files opened read/write.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0876::REFERENCE:CVE-2002-1694:DESCRIPTION:Log files opened read/write.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1694::
CWE-281: Improper Preservation of Permissions (Base)

Description: The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.




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

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



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::



Observed Examples: ::REFERENCE:CVE-2002-2323:DESCRIPTION:Incorrect ACLs used when restoring backups from directories that use symbolic links.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-2323::REFERENCE:CVE-2001-1515:DESCRIPTION:Automatic modification of permissions inherited from another file system.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1515::REFERENCE:CVE-2005-1920:DESCRIPTION:Permissions on backup file are created with defaults, possibly less secure than original file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1920::REFERENCE:CVE-2001-0195:DESCRIPTION:File is made world-readable when being cloned.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0195::
CWE-283: Unverified Ownership (Base)

Description: The product does not properly verify that a critical resource is owned by the proper entity.




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

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



Common Consequences: ::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:An attacker could gain unauthorized access to system resources.::


Potential Mitigations: ::PHASE:Architecture and Design Operation:DESCRIPTION:Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.::

Observed Examples: ::REFERENCE:CVE-2001-0178:DESCRIPTION:Program does not verify the owner of a UNIX socket that is used for sending a password.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0178::REFERENCE:CVE-2004-2012:DESCRIPTION:Owner of special device not checked, allowing root.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2012::



Notes: ::TYPE:Relationship:NOTE:This overlaps insufficient comparison, verification errors, permissions, and privileges.::
CWE-289: Authentication Bypass by Alternate Name (Base)

Description: The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.




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

Modes of Introduction: ::PHASE:Architecture and Design:NOTE:COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.::PHASE:Implementation::



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::


Potential Mitigations: ::PHASE:Architecture and Design:STRATEGY:Input Validation:DESCRIPTION:Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION: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 performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION: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 inputs after they have been checked.::

Observed Examples: ::REFERENCE:CVE-2003-0317:DESCRIPTION:Protection mechanism that restricts URL access can be bypassed using URL encoding.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0317::REFERENCE:CVE-2004-0847:DESCRIPTION:Bypass of authentication for files using (backslash) or %5C (encoded backslash).:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0847::



Notes: ::TYPE:Relationship:NOTE:Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.::TYPE:Theoretical:NOTE:Alternate names are useful in data driven manipulation attacks, not just for authentication.::
CWE-290: Authentication Bypass by Spoofing (Base)

Description: This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.





Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:IMPACT:Gain Privileges or Assume Identity:NOTE:This weakness can allow an attacker to access resources which are not otherwise accessible without proper authentication.::



Observed Examples: ::REFERENCE:CVE-2022-30319:DESCRIPTION:S-bus functionality in a home automation product performs access control using an IP allowlist, which can be bypassed by a forged IP address.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-30319::REFERENCE:CVE-2009-1048:DESCRIPTION:VOIP product allows authentication bypass using 127.0.0.1 in the Host header.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1048::



Notes: ::TYPE:Relationship:NOTE:This can be resultant from insufficient verification.::
CWE-294: Authentication Bypass by Capture-replay (Base)

Description: A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).

Extended Description: Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server.



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

Modes of Introduction: ::PHASE:Architecture and Design:NOTE:COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.::



Common Consequences: ::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication.::


Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.::PHASE:Architecture and Design:DESCRIPTION:Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.::

Observed Examples: ::REFERENCE:CVE-2005-3435:DESCRIPTION:product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3435::REFERENCE:CVE-2007-4961:DESCRIPTION:Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).:LINK:https://www.cve.org/CVERecord?id=CVE-2007-4961::
CWE-301: Reflection Attack in an Authentication Protocol (Base)

Description: Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.

Extended Description: A mutual authentication protocol requires each party to respond to a random challenge by the other party by encrypting it with a pre-shared key. Often, however, such protocols employ the same pre-shared key for communication with a number of different entities. A malicious user or an attacker can easily compromise this protocol without possessing the correct key by employing a reflection attack on the protocol. Reflection attacks capitalize on mutual authentication schemes in order to trick the target into revealing the secret shared between it and another valid user. In a basic mutual-authentication scheme, a secret is known to both the valid user and the server; this allows them to authenticate. In order that they may verify this shared secret without sending it plainly over the wire, they utilize a Diffie-Hellman-style scheme in which they each pick a value, then request the hash of that value as keyed by the shared secret. In a reflection attack, the attacker claims to be a valid user and requests the hash of a random value from the server. When the server returns this value and requests its own value to be hashed, the attacker opens another connection to the server. This time, the hash requested by the attacker is the value which the server requested in the first connection. When the server returns this hashed value, it is used in the first connection, authenticating the attacker successfully as the impersonated valid user.



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

Modes of Introduction: ::PHASE:Architecture and Design:NOTE:COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.::



Common Consequences: ::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:The primary result of reflection attacks is successful authentication with a target machine -- as an impersonated user.::


Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder.::PHASE:Architecture and Design:DESCRIPTION:Let the initiator prove its identity before proceeding.::

Observed Examples: ::REFERENCE:CVE-2005-3435:DESCRIPTION:product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3435::



Notes: ::TYPE:Maintenance:NOTE:The term reflection is used in multiple ways within CWE and the community, so its usage should be reviewed.::
CWE-303: Incorrect Implementation of Authentication Algorithm (Base)

Description: The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.

Extended Description: This incorrect implementation may allow authentication to be bypassed.



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

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



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::



Observed Examples: ::REFERENCE:CVE-2003-0750:DESCRIPTION:Conditional should have been an 'or' not an 'and'.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0750::
CWE-305: Authentication Bypass by Primary Weakness (Base)

Description: The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.




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

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



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::



Observed Examples: ::REFERENCE:CVE-2002-1374:DESCRIPTION:The provided password is only compared against the first character of the real password.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1374::REFERENCE:CVE-2000-0979:DESCRIPTION:The password is not properly checked, which allows remote attackers to bypass access controls by sending a 1-byte password that matches the first character of the real password.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0979::REFERENCE:CVE-2001-0088:DESCRIPTION:Chain: Forum software does not properly initialize an array, which inadvertently sets the password to a single character, allowing remote attackers to easily guess the password and gain administrative privileges.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0088::



Notes: ::TYPE:Relationship:NOTE:Most authentication bypass errors are resultant, not primary.::