Vulnerabilities in Linked Code
Vulnerability Info
Affected Versions
Description
Vulnerability Summary
The model aidiary/dqn-SpaceInvadersNoFrameskip-v4 is associated with a code repository https://github.com/DLR-RM/stable-baselines3 for which 807 CWEs (including 11 high severity vulnerabilities) were identified. The weaknesses and vulnerabilities listed here are for informational purposes about the model supply chain and may not be explicit in the model itself.
The model associated with aidiary/dqn-SpaceInvadersNoFrameskip-v4 has been found to have 5 Common Weakness Enumerations (CWEs), including 1 high severity vulnerability.
The identified weaknesses include:
- Improper Privilege Management (CWE-269)
- Execution with Unnecessary Privileges (CWE-250)
- Deserialization of Untrusted Data (CWE-502)
- Improper Check or Handling of Exceptional Conditions (CWE-703)
- Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') (CWE-78)
The GitHub repository is linked in the huggingface README.md.
The vulnerabilities were discovered using Semgrep and Bandit.
URL: https://huggingface.co/aidiary/dqn-SpaceInvadersNoFrameskip-v4
PURL: pkg:huggingface/aidiary/dqn-SpaceInvadersNoFrameskip-v4@532d9075432e0f2cb079a44fea5346a095282d9b
SHA: 532d9075432e0f2cb079a44fea5346a095282d9b
Author: aidiary
Tags: ['stable-baselines3', 'SpaceInvadersNoFrameskip-v4', 'deep-reinforcement-learning', 'reinforcement-learning', 'model-index', 'region:us']
Downloads: 4
Likes: 0
GitHub Link: https://github.com/DLR-RM/stable-baselines3
Low Severity Weaknesses: 793
Medium Severity Weaknesses: 3
High Severity Weaknesses: 11
Total Weaknesses Identified: 807
Common Weaknesses Enumerations (CWEs) Identified:
| CWE | Description | URL |
|---|---|---|
| CWE - 269 : Improper Privilege Management | The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. | 269 |
| CWE - 250 : Execution with Unnecessary Privileges | New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges. Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. | 250 |
| CWE - 502 : Deserialization of Untrusted Data | It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption. Data that is untrusted can not be trusted to be well-formed. When developers place no restrictions on gadget chains, or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell. | 502 |
| CWE - 703 : Improper Check or Handling of Exceptional Conditions | The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product. | 703 |
| CWE - 78 : Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') | This could allow attackers to execute unexpected, dangerous commands directly on the operating system. This weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications. Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have. The problem is exacerbated if the compromised process does not follow the principle of least privilege, because the attacker-controlled commands may run with special system privileges that increases the amount of damage. There are at least two subtypes of OS command injection: The application intends to execute a single, fixed program that is under its own control. It intends to use externally-supplied inputs as arguments to that program. For example, the program might use system(nslookup [HOSTNAME]) to run nslookup and allow the user to supply a HOSTNAME, which is used as an argument. Attackers cannot prevent nslookup from executing. However, if the program does not remove command separators from the HOSTNAME argument, attackers could place the separators into the arguments, which allows them to execute their own program after nslookup has finished executing. The application accepts an input that it uses to fully select which program to run, as well as which commands to use. The application simply redirects this entire command to the operating system. For example, the program might use exec([COMMAND]) to execute the [COMMAND] that was supplied by the user. If the COMMAND is under attacker control, then the attacker can execute arbitrary commands or programs. If the command is being executed using functions like exec() and CreateProcess(), the attacker might not be able to combine multiple commands together in the same line. From a weakness standpoint, these variants represent distinct programmer errors. In the first variant, the programmer clearly intends that input from untrusted parties will be part of the arguments in the command to be executed. In the second variant, the programmer does not intend for the command to be accessible to any untrusted party, but the programmer probably has not accounted for alternate ways in which malicious attackers can provide input. | 78 |