Vulnerabilities in Linked Code

Vulnerability Summary

The model 1daniar/ppo-SnowballTarget is associated with a code repository https://github.com/Unity-Technologies/ml-agents for which 935 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 1daniar/ppo-SnowballTarget has been found to have 10 Common Weakness Enumerations (CWEs), including 0 high severity vulnerabilities.

The identified weaknesses include:

• Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
• Cleartext Transmission of Sensitive Information
• Deserialization of Untrusted Data
• Use of a Broken or Risky Cryptographic Algorithm
• Incorrect Default Permissions
• Improper Neutralization of CRLF Sequences ('CRLF Injection')
• Insecure Temporary File
• Incorrect Permission Assignment for Critical Resource
• Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
• Improper Check or Handling of Exceptional Conditions

The GitHub repository is linked in the huggingface README.md.

The vulnerabilities were discovered using Semgrep and Bandit.

URL: https://huggingface.co/1daniar/ppo-SnowballTarget

PURL: pkg:huggingface/1daniar/ppo-SnowballTarget@26795677ac84c47f727b14d3e72edbe63e258327

SHA: 26795677ac84c47f727b14d3e72edbe63e258327

Author: 1daniar

Tags: ['ml-agents', 'tensorboard', 'onnx', 'SnowballTarget', 'deep-reinforcement-learning', 'reinforcement-learning', 'ML-Agents-SnowballTarget', 'region:us']

Downloads: 14

Likes: 0

GitHub Link: https://github.com/Unity-Technologies/ml-agents

Low Severity Weaknesses: 905

Medium Severity Weaknesses: 19

High Severity Weaknesses: 11

Total Weaknesses Identified: 935

Common Weaknesses Enumerations (CWEs) Identified:

CWE	Description	URL
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
CWE - 319 : Cleartext Transmission of Sensitive Information	Many communication channels can be sniffed (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data. Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries. When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to sniff the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.	319
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 - 327 : Use of a Broken or Risky Cryptographic Algorithm	Cryptographic algorithms are the methods by which data is scrambled to prevent observation or influence by unauthorized actors. Insecure cryptography can be exploited to expose sensitive information, modify data in unexpected ways, spoof identities of other users or devices, or other impacts. It is very difficult to produce a secure algorithm, and even high-profile algorithms by accomplished cryptographic experts have been broken. Well-known techniques exist to break or weaken various kinds of cryptography. Accordingly, there are a small number of well-understood and heavily studied algorithms that should be used by most products. Using a non-standard or known-insecure algorithm is dangerous because a determined adversary may be able to break the algorithm and compromise whatever data has been protected. Since the state of cryptography advances so rapidly, it is common for an algorithm to be considered unsafe even if it was once thought to be strong. This can happen when new attacks are discovered, or if computing power increases so much that the cryptographic algorithm no longer provides the amount of protection that was originally thought. For a number of reasons, this weakness is even more challenging to manage with hardware deployment of cryptographic algorithms as opposed to software implementation. First, if a flaw is discovered with hardware-implemented cryptography, the flaw cannot be fixed in most cases without a recall of the product, because hardware is not easily replaceable like software. Second, because the hardware product is expected to work for years, the adversary's computing power will only increase over time.	327
CWE - 276 : Incorrect Default Permissions	During installation, installed file permissions are set to allow anyone to modify those files.	276
CWE - 93 : Improper Neutralization of CRLF Sequences ('CRLF Injection')	The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.	93
CWE - 377 : Insecure Temporary File	Creating and using insecure temporary files can leave application and system data vulnerable to attack.	377
CWE - 732 : Incorrect Permission Assignment for Critical Resource	When a resource is given a permission setting that provides access to a wider range of actors than required, it could lead to the exposure of sensitive information, or the modification of that resource by unintended parties. This is especially dangerous when the resource is related to program configuration, execution, or sensitive user data. For example, consider a misconfigured storage account for the cloud that can be read or written by a public or anonymous user.	732
CWE - 22 : Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')	Many file operations are intended to take place within a restricted directory. By using special elements such as .. and / separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the ../ sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as /usr/local/bin, which may also be useful in accessing unexpected files. This is referred to as absolute path traversal. In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the product may add .txt to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.	22
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