Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pytest-7.4.4-py3-none-any.whl: 1 vulnerabilities (highest severity is: 3.3) #631

Closed
TheComputerGenie opened this issue Oct 1, 2024 · 1 comment · Fixed by #632
Closed

Comments

@TheComputerGenie
Copy link

Vulnerable Library - pytest-7.4.4-py3-none-any.whl

Path to dependency file: /src/cryptoconditions/test-requirements.txt

Path to vulnerable library: /src/cryptoconditions/test-requirements.txt

Found in HEAD commit: 0adeeabdd484ef40539d1275c6a765f5c530ea79

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (pytest version) Automated Remediation Possible**
CVE-2024-5569 Low 3.3 zipp-3.15.0-py3-none-any.whl Transitive 8.0.0

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2024-5569

Vulnerable Library - zipp-3.15.0-py3-none-any.whl

Backport of pathlib-compatible object wrapper for zip files

Library home page: https://files.pythonhosted.org/packages/5b/fa/c9e82bbe1af6266adf08afb563905eb87cab83fde00a0a08963510621047/zipp-3.15.0-py3-none-any.whl

Path to dependency file: /src/cryptoconditions/test-requirements.txt

Path to vulnerable library: /src/cryptoconditions/test-requirements.txt

Dependency Hierarchy:

  • pytest-7.4.4-py3-none-any.whl (Root Library)
    • importlib_metadata-6.7.0-py3-none-any.whl
      • zipp-3.15.0-py3-none-any.whl (Vulnerable Library)

Found in HEAD commit: 0adeeabdd484ef40539d1275c6a765f5c530ea79

Found in base branch: master

Vulnerability Details

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the Path module in both zipp and zipfile, such as joinpath, the overloaded division operator, and iterdir. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.

Publish Date: 2024-07-09

URL: CVE-2024-5569

CVSS 3 Score Details (3.3)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Local
    • Attack Complexity: Low
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://huntr.com/bounties/be898306-11f9-46b4-b28c-f4c4aa4ffbae

Release Date: 2024-07-09

Fix Resolution (zipp): 3.19.1

Direct dependency fix Resolution (pytest): 8.0.0

DeckerSU added a commit that referenced this issue Oct 2, 2024
DeckerSU added a commit to DeckerSU/KomodoOcean that referenced this issue Oct 2, 2024
@DeckerSU DeckerSU linked a pull request Oct 2, 2024 that will close this issue
6 tasks
DeckerSU added a commit that referenced this issue Oct 3, 2024
* cc: fix ed25519 signatures malleability

- #630
- https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/#vuln-ed25519

Actually, the current CC code doesn’t use Ed25519 signatures, so `CVE-2024-45193` has no impact on Komodo (KMD) or any existing assetchains. However, since CC could potentially use these types of signatures in the future (e.g., for newly developed CCs), we’ve added a `0 <= s < L` check to prevent signature malleability.

* add ed25519 signature malleability test

* use int instead of size_t in 0 <= s < L check loop

using a signed integer type (int) is preferable here,
to avoid potential issues with unsigned underflow.

* cc: test, update pytest ver. requirement

addressed in #631
@DeckerSU
Copy link

DeckerSU commented Oct 3, 2024

Closed as fixed in #632 .

@DeckerSU DeckerSU closed this as completed Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants