Vulnerabilities in Linked Code
0% found this helpful
Vulnerability Info
Model Namepkg:huggingface/timm/resnet50.a1_in1k
Vulnerability Typesecurity
CVE Number
Created Date2024/06/27
Reported By@indiana-university
References
Affected Versions
@93271f4677dbf7b4d7f7e7d9d7811bd66c327e5605 April 2023
Description
Vulnerability Summary
The model timm/resnet50.a1_in1k is associated with a code repository https://github.com/huggingface/pytorch-image-models for which 598 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 timm/resnet50.a1_in1k has been found to have 7 Common Weaknesses Enumerations (CWEs), including 5 high severity vulnerabilities.
The identified weaknesses include:
- Deserialization of Untrusted Data
- Improper Encoding or Escaping of Output
- Improper Check or Handling of Exceptional Conditions
- Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
- Improper Control of Generation of Code ('Code Injection')
- Use of Insufficiently Random Values
- Use of Hard-coded Password
The GitHub repository is linked in the huggingface README.md.
The vulnerabilities were discovered using Semgrep and Bandit.
URL: https://huggingface.co/timm/resnet50.a1_in1k
PURL: pkg:huggingface/timm/resnet50.a1_in1k@93271f4677dbf7b4d7f7e7d9d7811bd66c327e56
SHA: 93271f4677dbf7b4d7f7e7d9d7811bd66c327e56
Author: timm
Tags: ['timm', 'pytorch', 'safetensors', 'image-classification', 'arxiv:2110.00476', 'arxiv:1512.03385', 'license:apache-2.0', 'has_space', 'region:us']
Downloads: 3111680
Likes: 11
GitHub Link: https://github.com/huggingface/pytorch-image-models
Low Severity Weaknesses: 583
Medium Severity Weaknesses: 4
High Severity Weaknesses: 11
Total Weaknesses Identified: 598
Common Weaknesses Enumerations (CWEs) Identified:
| CWE | Description | URL |
|---|---|---|
| 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 - 116 : Improper Encoding or Escaping of Output | Improper encoding or escaping can allow attackers to change the commands that are sent to another component, inserting malicious commands instead. Most products follow a certain protocol that uses structured messages for communication between components, such as queries or commands. These structured messages can contain raw data interspersed with metadata or control information. For example, GET /index.html HTTP/1.1 is a structured message containing a command (GET) with a single argument (/index.html) and metadata about which protocol version is being used (HTTP/1.1). If an application uses attacker-supplied inputs to construct a structured message without properly encoding or escaping, then the attacker could insert special characters that will cause the data to be interpreted as control information or metadata. Consequently, the component that receives the output will perform the wrong operations, or otherwise interpret the data incorrectly. | 116 |
| 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 |
| CWE - 94 : Improper Control of Generation of Code ('Code Injection') | When a product allows a user's input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the product. Such an alteration could lead to arbitrary code execution. Injection problems encompass a wide variety of issues -- all mitigated in very different ways. For this reason, the most effective way to discuss these weaknesses is to note the distinct features which classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities. | 94 |
| CWE - 330 : Use of Insufficiently Random Values | When product generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. | 330 |
| CWE - 259 : Use of Hard-coded Password | A hard-coded password typically leads to a significant authentication failure that can be difficult for the system administrator to detect. Once detected, it can be difficult to fix, so the administrator may be forced into disabling the product entirely. There are two main variations: Inbound: the product contains an authentication mechanism that checks for a hard-coded password. Outbound: the product connects to another system or component, and it contains hard-coded password for connecting to that component. In the Inbound variant, a default administration account is created, and a simple password is hard-coded into the product and associated with that account. This hard-coded password is the same for each installation of the product, and it usually cannot be changed or disabled by system administrators without manually modifying the program, or otherwise patching the product. If the password is ever discovered or published (a common occurrence on the Internet), then anybody with knowledge of this password can access the product. Finally, since all installations of the product will have the same password, even across different organizations, this enables massive attacks such as worms to take place. The Outbound variant applies to front-end systems that authenticate with a back-end service. The back-end service may require a fixed password which can be easily discovered. The programmer may simply hard-code those back-end credentials into the front-end product. Any user of that program may be able to extract the password. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple. | 259 |