📦 Bump versions of multiple dependencies to address vulnerabilities #23
Conversation
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Lineaje has automatically created this pull request to resolve the following CVEs:
PackageIndexwas fixed in setuptools version 78.1.1 ### Details
def<br>_download_url(self, url, tmpdir): # Determine download<br>filename # name, _fragment = egg_info_for_url(url) if name:<br>while '..' in name: name = name.replace('..',<br>'.').replace('\\', '_') else: name = "__downloaded__" #<br>default if URL has no path contents if<br>name.endswith('.[egg.zip](http://egg.zip/)'): name =<br>name[:-4] # strip the extra .zip before download --> filename<br>= os.path.join(tmpdir, name)Here:https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/package_index.py#L810C1-L825C88
os.path.join()discards the first argumenttmpdirif thesecond begins with a slash or drive letter.
nameis derivedfrom a URL without sufficient sanitization. While there is
some attempt to sanitize by replacing instances of '..' with
'.', it is insufficient. ### Risk Assessment As easy_install
and package_index are deprecated, the exploitation surface is
reduced. However, it seems this could be exploited in a
similar fashion like
GHSA-r9hx-vwmv-q579, and as
described by POC 4 in
GHSA-cx63-2mw6-8hw5 report: via
malicious URLs present on the pages of a package index. ###
Impact An attacker would be allowed to write files to
arbitrary locations on the filesystem with the permissions of
the process running the Python code, which could escalate to
RCE depending on the context. ### References
https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5
pypa/setuptools#4946
implementation where a user can exhaust memory on the host
due to goroutine leaks. Repetitive calls of CRI Attach (e.g.,
kubectl<br>attach)could increase the memory usage of containerd. ### Patches
This bug has been fixed in the following containerd versions:
* 2.2.0 * 2.1.5 * 2.0.7 * 1.7.29 Users should update to these
versions to resolve the issue. ### Workarounds Set up an
admission controller to control accesses to
pods/attachresources. e.g., Validating Admission
Policy.
### Credits The containerd project would like to thank
@Wheat2018 for responsibly disclosing this issue in
accordance with the containerd security
policy.
### References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329
### For more information If you have any questions or
comments about this advisory: * Open an issue in
containerd
* Email us at
[email protected] To
report a security issue in containerd: * Report a new
vulnerability
was found in containerd. -
/var/lib/containerdwas createdwith the permission bits 0o711, while it should be created
with 0o700 - Allowed local users on the host to potentially
access the metadata store and the content store -
/run/containerd/io.containerd.grpc.v1.criwas created with0o755, while it should be created with 0o700 - Allowed local
users on the host to potentially access the contents of
Kubernetes local volumes. The contents of volumes might
include setuid binaries, which could allow a local user on
the host to elevate privileges on the host. -
/run/containerd/io.containerd.sandbox.controller.v1.shimwas created with 0o711, while it should be created with 0o700
The directory paths may differ depending on the daemon
configuration. When the
tempdirectory path is specified inthe daemon configuration, that directory was also created
with 0o711, while it should be created with 0o700. ###
Patches This bug has been fixed in the following containerd
versions: * 2.2.0 * 2.1.5 * 2.0.7 * 1.7.29 Users should
update to these versions to resolve the issue. These updates
automatically change the permissions of the existing
directories. > [!NOTE] > >
/run/containerdand/run/containerd/io.containerd.runtime.v2.taskare stillcreated with 0o711. > This is an expected behavior for
supporting userns-remapped containers. ### Workarounds The
system administrator on the host can manually chmod the
directories to not have group or world accessible
permisisons:
chmod 700 /var/lib/containerd chmod 700<br>/run/containerd/io.containerd.grpc.v1.cri chmod 700<br>/run/containerd/io.containerd.sandbox.controller.v1.shimAn alternative mitigation would be to run containerd in
rootless
mode.
### Credits The containerd project would like to thank David
Leadbeater for responsibly disclosing this issue in
accordance with the containerd security
policy.
### For more information If you have any questions or
comments about this advisory: * Open an issue in
containerd
* Email us at
[email protected] To
report a security issue in containerd: * Report a new
vulnerability
launched with a User set as a
UID:GIDlarger than themaximum 32-bit signed integer can cause an overflow condition
where the container ultimately runs as root (UID 0). This
could cause unexpected behavior for environments that require
containers to run as a non-root user. ### Patches This bug
has been fixed in the following containerd versions: * 2.0.4
(Fixed in
containerd/containerd@1a43cb6)
* 1.7.27 (Fixed in
containerd/containerd@05044ec)
* 1.6.38 (Fixed in
containerd/containerd@cf158e8)
Users should update to these versions to resolve the issue.
### Workarounds Ensure that only trusted images are used and
that only trusted users have permissions to import images.
### Credits The containerd project would like to thank
Benjamin Koltermann and
emxll for responsibly disclosing
this issue in accordance with the containerd security
policy.
### References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-40635
### For more information If you have any questions or
comments about this advisory: * Open an issue in
containerd
Email us at
[email protected] To
report a security issue in containerd: * Report a new
vulnerability
* Email us at
[email protected]
Connector
is a pure Python connector to Redshift (i.e., driver) that
implements the Python Database API Specification
2.0. When the
Amazon Redshift Python Connector is configured with the
BrowserAzureOAuth2CredentialsProvider plugin, the driver
skips the SSL certificate validation step for the Identity
Provider. ### Impact An insecure connection could allow an
actor to intercept the token exchange process and retrieve an
access token. Impacted versions: >=2.0.872;<=2.1.6 ###
Patches Upgrade Amazon Redshift Python Connector to version
2.1.7 and ensure any forked or derivative code is patched to
incorporate the new fixes. ### Workarounds None ###
References If you have any questions or comments about this
advisory we ask that you contact AWS/Amazon Security via our
vulnerability reporting page [1] or directly via email to
[email protected].
Please do not create a public GitHub issue. [1] Vulnerability
reporting page:
https://aws.amazon.com/security/vulnerability-reporting
in the Snowflake Connector for Python. The OCSP response
cache uses pickle as the serialization format, potentially
leading to local privilege escalation. This vulnerability
affects versions 2.7.12 through 3.13.0. Snowflake fixed the
issue in version 3.13.1. ### Vulnerability Details The OCSP
response cache is saved locally on the machine running the
Connector using the pickle serialization format. This can
potentially lead to local privilege escalation if an attacker
has write access to the OCSP response cache file. ###
Solution Snowflake released version 3.13.1 of the Snowflake
Connector for Python, which fixes this issue. We recommend
users upgrade to version 3.13.1. ### Additional Information
If you discover a security vulnerability in one of our
products or websites, please report the issue to HackerOne.
For more information, please see our Vulnerability
Disclosure
Policy.
in the Snowflake Connector for Python. A function from the
snowflake.connector.pandas_tools module is vulnerable to SQL
injection. This vulnerability affects versions 2.2.5 through
3.13.0. Snowflake fixed the issue in version 3.13.1. ###
Vulnerability Details A function from the
snowflake.connector.pandas_tools module is not sanitizing all
of its arguments, and queries using them are not
parametrized. An attacker controlling these arguments could
achieve SQL injection by passing crafted input. Any SQL
executed that way by an attacker would still run in the
context of the current session. ### Solution Snowflake
released version 3.13.1 of the Snowflake Connector for
Python, which fixes this issue. We recommend users upgrade to
version 3.13.1. ### Additional Information If you discover a
security vulnerability in one of our products or websites,
please report the issue to HackerOne. For more information,
please see our Vulnerability Disclosure
Policy.
in the Snowflake Connector for Python. On Linux systems, when
temporary credential caching is enabled, the Snowflake
Connector for Python will cache temporary credentials locally
in a world-readable file. This vulnerability affects versions
2.3.7 through 3.13.0. Snowflake fixed the issue in version
3.13.1. ### Vulnerability Details On Linux, when either
EXTERNALBROWSER or USERNAME_PASSWORD_MFA authentication
methods are used with temporary credential caching enabled,
the Snowflake Connector for Python will cache the temporary
credentials in a local file. In the vulnerable versions of
the Driver, this file is created with world-readable
permissions. ### Solution Snowflake released version 3.13.1
of the Snowflake Connector for Python, which fixes this
issue. We recommend users upgrade to version 3.13.1. ###
Additional Information If you discover a security
vulnerability in one of our products or websites, please
report the issue to HackerOne. For more information, please
see our Vulnerability Disclosure
Policy.
components through repeated string concatenation. When
parsing large domain-literal components, this can cause
excessive CPU consumption.
contains attacker controlled information (the ALPN protocols
sent by the client) which is not escaped.
non-linearly with respect to the size of the input. This
affects programs which parse untrusted PEM inputs.
to be included in square brackets within the host component
of a URL. RFC 3986 permits IPv6 addresses to be included
within the host component, enclosed within square brackets.
For example: "http://[::1]/". IPv4 addresses and hostnames
must not appear within square brackets. Parse did not enforce
this requirement.
large amounts of memory, causing memory exhaustion.
number of cookies that can be parsed does not have a limit.
By sending a lot of very small cookies such as "a=;", an
attacker can make an HTTP server allocate a large amount of
structs, causing large memory consumption.
can cause programs to panic, due to a interface cast that
assumes they implement the Equal method. This affects
programs which validate arbitrary certificate chains.
sparse region data blocks in GNU tar pax 1.0 sparse files. A
maliciously-crafted archive containing a large number of
sparse regions can cause a Reader to read an unbounded amount
of data from the archive into memory. When reading from a
compressed source, a small compressed input can result in
large allocations.
through repeated string concatenation of lines. When the
number of lines in a response is large, this can cause
excessive CPU consumption.
ID may incorrectly satisfy a URI name constraint that applies
to the certificate chain. Certificates containing URIs are
not permitted in the web PKI, so this only affects users of
private PKIs which make use of URIs.
cross-domain redirect. For example, a request to a.com/
containing an Authorization header which is redirected to
b.com/ will not send that header to b.com. In the event that
the client received a subsequent same-domain redirect,
however, the sensitive headers would be restored. For
example, a chain of redirects from a.com/, to b.com/1, and
finally to b.com/2 would incorrectly send the Authorization
header to b.com/2.
assembly implementation of an internal function, a small
number of bits of secret scalars are leaked on the ppc64le
architecture. Due to the way this function is used, we do not
believe this leakage is enough to allow recovery of the
private key when P-256 is used in any well known protocols.
terminator in chunked data chunk-size lines. This can permit
request smuggling if a net/http server is used in conjunction
with a server that incorrectly accepts a bare LF as part of a
chunk-ext.
on cross-origin redirects potentially leaking sensitive
information.
one of the query methods) during a call to the Scan method of
the returned Rows can result in unexpected results if other
queries are being made in parallel. This can result in a race
condition that may overwrite the expected results with those
of another query, causing the call to Scan to return either
unexpected results from the other query or an error.
executables (rather than just directories), passing certain
strings to LookPath ("", ".", and ".."), can result in the
binaries listed in the PATH being unexpectedly returned.
an input file and it has deeply nested data, Jackson could
end up throwing a StackoverflowError if the depth is
particularly large. ### Patches jackson-core 2.15.0 contains
a configurable limit for how deep Jackson will traverse in an
input document, defaulting to an allowable depth of 1000.
Change is in
FasterXML/jackson-core#943.
jackson-core will throw a StreamConstraintsException if the
limit is reached. jackson-databind also benefits from this
change because it uses jackson-core to parse JSON inputs. ###
Workarounds Users should avoid parsing input files from
untrusted sources.
chunked-coding message bodies can lead to request smuggling
vulnerabilities under certain conditions. ### Details
HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence
of "chunks", each of which consists of: - chunk length -
\r\n-lengthbytes of content -\r\nIn versions ofh11 up to 0.14.0, h11 instead parsed them as: - chunk length
-
\r\n-lengthbytes of content - any two bytes i.e. itdid not validate that the trailing
\r\nbytes were correct,and if you put 2 bytes of garbage there it would be accepted,
instead of correctly rejecting the body as malformed. By
itself this is harmless. However, suppose you have a proxy or
reverse-proxy that tries to analyze HTTP requests, and your
proxy has a different bug in parsing Chunked-Encoding,
acting as if the format is: - chunk length -
\r\n-lengthbytes of content - more bytes of content, as many asit takes until you find a
\r\nFor example,pound had this
bug -- it can happen if an implementer uses a generic "read
until end of line" helper to consumes the trailing
\r\n. Inthis case, h11 and your proxy may both accept the same stream
of bytes, but interpret them differently. For example,
consider the following HTTP request(s) (assume all line
breaks are
\r\n):GET /one HTTP/1.1 Host: localhost<br>Transfer-Encoding: chunked 5 AAAAAXX2 45 0 GET /two HTTP/1.1<br>Host: localhost Transfer-Encoding: chunked 0Here h11will interpret it as two requests, one with body
AAAAA45and one with an empty body, while our hypothetical buggy
proxy will interpret it as a single request, with body
AAAAXX20\r\n\r\nGET /two .... And any time two HTTPprocessors both accept the same string of bytes but interpret
them differently, you have the conditions for a "request
smuggling" attack. For example, if
/twois a dangerousendpoint and the job of the reverse proxy is to stop requests
from getting there, then an attacker could use a bytestream
like the above to circumvent this protection. Even worse, if
our buggy reverse proxy receives two requests from different
users:
GET /one HTTP/1.1 Host: localhost<br>Transfer-Encoding: chunked 5 AAAAAXX999 0GET /two<br>HTTP/1.1 Host: localhost Cookie: SESSION_KEY=abcdef......it will consider the first request to be complete and
valid, and send both on to the h11-based web server over the
same socket. The server will then see the two concatenated
requests, and interpret them as one request to
/onewhosebody includes
/two's session key, potentially allowing oneuser to steal another's credentials. ### Patches Fixed in h11
0.15.0. ### Workarounds Since exploitation requires the
combination of buggy h11 with a buggy (reverse) proxy, fixing
either component is sufficient to mitigate this issue. ###
Credits Reported by Jeppe Bonde Weikop on 2025-01-09.
special BeanIntrospector class was added in version 1.9.2.
This can be used to stop attackers from using the declared
class property of Java enum objects to get access to the
classloader. However this protection was not enabled by
default. PropertyUtilsBean (and consequently BeanUtilsBean)
now disallows declared class level property access by
default. Releases 1.11.0 and 2.0.0-M2 address a potential
security issue when accessing enum properties in an
uncontrolled way. If an application using Commons BeanUtils
passes property paths from an external source directly to the
getProperty() method of PropertyUtilsBean, an attacker can
access the enum’s class loader via the “declaredClass”
property available on all Java “enum” objects. Accessing
the enum’s “declaredClass” allows remote attackers to
access the ClassLoader and execute arbitrary code. The same
issue exists with PropertyUtilsBean.getNestedProperty().
Starting in versions 1.11.0 and 2.0.0-M2 a special
BeanIntrospector suppresses the “declaredClass” property.
Note that this new BeanIntrospector is enabled by default,
but you can disable it to regain the old behavior; see
section 2.5 of the user's guide and the unit tests. This
issue affects Apache Commons BeanUtils 1.x before 1.11.0, and
2.x before 2.0.0-M2.Users of the artifact
commons-beanutils:commons-beanutils 1.x are recommended to
upgrade to version 1.11.0, which fixes the issue. Users of
the artifact org.apache.commons:commons-beanutils2 2.x are
recommended to upgrade to version 2.0.0-M2, which fixes the
issue.
version of CVE-2019-19921, which was a flaw which allowed an
attacker to trick runc into writing the LSM process labels
for a container process into a dummy
tmpfsfile and thusnot apply the correct LSM labels to the container process.
The mitigation runc applied for CVE-2019-19921 was fairly
limited and effectively only caused runc to verify that when
runc writes LSM labels that those labels are actual procfs
files. Rather than using a fake
tmpfsfile for/proc/self/attr/<label>, an attacker could instead (throughvarious means) make
/proc/self/attr/<label>reference areal
procfsfile, but one that would still be a no-op (suchas
/proc/self/sched). This would have the same effect butwould clear the "is a procfs file" check. Runc is aware that
this kind of attack would be possible (even going so far as
to discuss this publicly as "future work" at conferences),
and runc is working on a far more comprehensive mitigation of
this attack, but this security issue was disclosed before
runc could complete this work. In all known versions of runc,
an attacker can trick runc into misdirecting writes to
/procto other procfs files through the use of a racingcontainer with shared mounts (runc has also verified this
attack is possible to exploit using a standard Dockerfile
with
docker buildx buildas that also permits triggeringparallel execution of containers with custom shared mounts
configured). This redirect could be through symbolic links in
a
tmpfsor theoretically other methods such as regularbind-mounts. Note that while
/proc/self/attr/<label>wasthe example used above (which is LSM-specific), this issue
affect all writes to
/procin runc and thus also affectssysctls (written to
/proc/sys/...) and some other APIs.#### Additional Impacts #### While investigating this issue,
runc discovered that another risk with these redirected
writes is that they could be redirected to dangerous files
such as
/proc/sysrq-triggerrather than just no-op fileslike
/proc/self/sched. For instance, the default AppArmorprofile name in Docker is
docker-default, which whenwritten to
/proc/sysrq-triggerwould cause the host systemto crash. When this was discovered, runc conducted an audit
of other write operations within runc and found several
possible areas where runc could be used as a semi-arbitrary
write gadget when combined with the above race attacks. The
most concerning attack scenario was the configuration of
sysctls. Because the contents of the sysctl are free-form
text, an attacker could use a misdirected write to write to
/proc/sys/kernel/core_patternand break out of thecontainer (as described in CVE-2025-31133, kernel upcalls are
not namespaced and so coredump helpers will run with complete
root privileges on the host). Even if the attacker cannot
configure custom sysctls, a valid sysctl string (when
redirected to
/proc/sysrq-trigger) can easily cause themachine to hang. Note that the fact that this attack allows
you to disable LSM labels makes it a very useful attack to
combine with CVE-2025-31133 (as one of the only mitigations
available to most users for that issue is AppArmor, and this
attack would let you bypass that). However, the misdirected
write issue above means that you could also achieve most of
the same goals without needing to chain together attacks. ###
Patches ### This advisory is being published as part of a set
of three advisories: * CVE-2025-31133 * CVE-2025-52881 *
CVE-2025-52565 The patches fixing this issue have accordingly
been combined into a single patchset. The following patches
from that patchset resolve the issues in this advisory:
db19bbed5348 ("internal/sys: add VerifyInode helper")
6fc191449109 ("internal: move utils.MkdirAllInRoot to
internal/pathrs") * ff94f9991bd3 (": switch to safer
securejoin.Reopen") * 44a0fcf685db ("go.mod: update to
github.com/cyphar/[email protected]") * 77889b56db93
("internal: add wrappers for securejoin.Proc") *
fdcc9d3cad2f ("apparmor: use safe procfs API for labels") *
ff6fe1324663 ("utils: use safe procfs for /proc/self/fd loop
code") * b3dd1bc562ed ("utils: remove unneeded
EnsureProcHandle") * 77d217c7c377 ("init: write sysctls using
safe procfs API") * 435cc81be6b7 ("init: use securejoin for
/proc/self/setgroups") * d61fd29d854b ("libct/system: use
securejoin for /proc/$pid/stat") * 4b37cd93f86e ("libct:
align param type for mountCgroupV1/V2 functions") *
d40b3439a961 ("rootfs: switch to fd-based handling of
mountpoint targets") * ed6b1693b8b3 ("selinux: use safe
procfs API for labels") - Please note that this patch
includes a private patch for
github.com/opencontainers/selinuxthat could not be madepublic through a public pull request (as it would necessarily
disclose this embargoed security issue). The patch includes a
complete copy of the forked code and a
replacedirective(as well as
go mod vendorapplied), which should still workwith downstream build systems. If you cannot apply this
patch, you can safely drop it -- some of the other patches in
this series should block these kinds of racing mount attacks
entirely. See
opencontainers/selinux#237 for the
upstream patch. * 3f925525b44d ("rootfs: re-allow dangling
symlinks in mount targets") * a41366e74080 ("openat2: improve
resilience on busy systems") runc 1.2.8, 1.3.3, and
1.4.0-rc.3 have been released and all contain fixes for these
issues. As per [runc's new release model][RELEASES.md], runc
1.1.x and earlier are no longer supported and thus have not
been patched. [CVE-2025-31133]:
GHSA-9493-h29p-rfm2
[CVE-2025-52565]:
GHSA-qw9x-cqr3-wc7r
[CVE-2025-52881]:
GHSA-cgrx-mc8f-2prm
[RELEASES.md]:
https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md
### Mitigations ### * Do not run untrusted container images
from unknown or unverified sources. * For the basic no-op
attack, this attack allows a container process to run with
the same LSM labels as
runc. For most AppArmor deploymentsthis means it will be
unconfined, and for SELinux it willlikely be
container_runtime_t. Runc has not conductedin-depth testing of the impact on SELinux -- it is possible
that it provides some reasonable protection but it seems
likely that an attacker could cause harm to systems even with
such an SELinux setup. * For the more involved redirect and
write gadget attacks, unfortunately most LSM profiles
(including the standard container-selinux profiles) provide
the container runtime access to sysctl files (including
/proc/sysrq-trigger) and so LSMs likely do not provide muchprotection against these attacks. * Using rootless containers
provides some protection against these kinds of bugs
(privileged writes in runc being redirected) -- by having
runc itself be an unprivileged process, in general you would
expect the impact scope of a runc bug to be less severe as it
would only have the privileges afforded to the host user
which spawned runc. For this particular bug, the privilege
escalation caused by the inadvertent write issue is entirely
mitigated with rootless containers because the unprivileged
user that the
runcprocess is executing as cannot write tothe aforementioned procfs files (even intentionally). ###
Other Runtimes ### As this vulnerability boils down to a
fairly easy-to-make logic bug, runc has provided information
to other OCI (crun, youki) and non-OCI (LXC) container
runtimes about this vulnerability. Based on discussions with
other runtimes, it seems that crun and youki may have similar
security issues and will release a co-ordinated security
release along with runc. LXC appears to use the host's
/procfor all procfs operations, and so is likely notvulnerable to this issue (this is a trade-off -- runc uses
the container's procfs to avoid CVE-2016-9962-style attacks).
[CVE-2016-9962]:
https://seclists.org/fulldisclosure/2017/Jan/21 ### Credits
### Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC)
and Tõnis Tiigi (@tonistiigi from Docker) for both
independently discovering this vulnerability, as well as
Aleksa Sarai (@cyphar from SUSE) for the original research
into this class of security issues and solutions. Additional
thanks go to Tõnis Tiigi for finding some very useful
exploit templates for these kinds of race attacks using
docker buildx build.backend to parse untrusted Protocol Buffers data containing
an arbitrary number of recursive groups, recursive
messages or a series of
SGROUPtags can be corrupted by exceeding the Python recursion
limit. Reporter: Alexis Challande, Trail of Bits Ecosystem
Security Team
[email protected]
Affected versions: This issue only affects the pure-Python
implementation
of protobuf-python backend. This is the implementation when
PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=pythonenvironmentvariable is set or the default when protobuf is used from
Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not
use pure-Python by default. This is a Python variant of a
previous issue affecting
protobuf-java.
### Severity This is a potential Denial of Service. Parsing
nested protobuf data creates unbounded recursions that can be
abused by an attacker. ### Proof of Concept For reproduction
details, please refer to the unit tests
decoder_test.py
and
message_test
### Remediation and Mitigation A mitigation is available now.
Please update to the latest available versions of the
following packages: * protobuf-python(4.25.8, 5.29.5, 6.31.1)
an input file and it has deeply nested data, Jackson could
end up throwing a StackoverflowError if the depth is
particularly large. ### Patches jackson-core 2.15.0 contains
a configurable limit for how deep Jackson will traverse in an
input document, defaulting to an allowable depth of 1000.
Change is in
FasterXML/jackson-core#943.
jackson-core will throw a StreamConstraintsException if the
limit is reached. jackson-databind also benefits from this
change because it uses jackson-core to parse JSON inputs. ###
Workarounds Users should avoid parsing input files from
untrusted sources.
JsonLocation._appendSourceDescmethod allows up to 500bytes of unintended memory content to be included in
exception messages. When parsing JSON from a byte array with
an offset and length, the exception message incorrectly reads
from the beginning of the array instead of the logical
payload start. This results in possible information
disclosure in systems using pooled or reused buffers,
like Netty or Vert.x. ### Details The vulnerability affects
the creation of exception messages like:
<br>JsonParseException: Unexpected character ... at [Source:<br>(byte[])...]WhenJsonFactory.createParser(byte[] data,<br>int offset, int len)is used, and an error occurs whileparsing, the exception message should include a snippet from
the specified logical payload. However, the method
_appendSourceDescignores theoffset, and always startsreading from index
0. If the buffer contains residualsensitive data from a previous request, such as credentials
or document contents, that data may be exposed if the
exception is propagated to the client. The issue particularly
impacts server applications using: * Pooled byte buffers
(e.g., Netty) * Frameworks that surface parse errors in HTTP
responses * Default Jackson settings (i.e.,
INCLUDE_SOURCE_IN_LOCATIONis enabled) A documentedreal-world example is
CVE-2021-22145
in Elasticsearch, which stemmed from the same root cause. ###
Attack Scenario An attacker sends malformed JSON to a service
using Jackson and pooled byte buffers (e.g., Netty-based HTTP
servers). If the server reuses a buffer and includes the
parser’s exception in its HTTP 400 response, the attacker
may receive residual data from previous requests. ### Proof
of Concept
java byte[] buffer = new byte[1000];<br>System.arraycopy("SECRET".getBytes(), 0, buffer, 0, 6);<br>System.arraycopy("{ \"bad\": }".getBytes(), 0, buffer, 700,<br>10); JsonFactory factory = new JsonFactory(); JsonParser<br>parser = factory.createParser(buffer, 700, 20);<br>parser.nextToken(); // throws exception // Exception message<br>will include "SECRET"### Patches This issue was silentlyfixed in jackson-core version 2.13.0, released on September
30, 2021, via PR
#652.
All users should upgrade to version 2.13.0 or later. ###
Workarounds If upgrading is not immediately possible,
applications can mitigate the issue by: 1. Disabling
exception message exposure to clients — avoid returning
parsing exception messages in HTTP responses. 2. Disabling
source inclusion in exceptions by setting:
java<br>jsonFactory.disable(JsonFactory.Feature.INCLUDE_SOURCE_IN_LOCATION);<br>This prevents Jackson from embedding any source contentin exception messages, avoiding leakage. ### References
Pull Request #652 (Fix
implementation)
CVE-2021-22145 (Elasticsearch exposure of this
flaw)
vulnerability in HTTP/2, which we refer to as
“MadeYouReset.” ### MadeYouReset Vulnerability Summary
The MadeYouReset DDoS vulnerability is a logical
vulnerability in the HTTP/2 protocol, that uses malformed
HTTP/2 control frames in order to break the max concurrent
streams limit - which results in resource exhaustion and
distributed denial of service. ### Mechanism The
vulnerability uses malformed HTTP/2 control frames, or
malformed flow, in order to make the server reset streams
created by the client (using the RST_STREAM frame). The
vulnerability could be triggered by several primitives,
defined by the RFC of HTTP/2 (RFC 9113). The Primitives are:
1. WINDOW_UPDATE frame with an increment of 0 or an increment
that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1)
2. HEADERS or DATA frames sent on a half-closed (remote)
stream (which was closed using the END_STREAM flag). (note
that for some implementations it's possible a CONTINUATION
frame to trigger that as well - but it's very rare). (Section
5.1) 3. PRIORITY frame with a length other than 5. (section
6.3) From our experience, the primitives are likely to exist
in the decreasing order listed above. Note that based on the
implementation of the library, other primitives (which are
not defined by the RFC) might exist - meaning scenarios in
which RST_STREAM is not supposed to be sent, but in the
implementation it does. On the other hand - some RFC-defined
primitives might not work, even though they are defined by
the RFC (as some implementations are not fully complying with
RFC). For example, some implementations we’ve seen discard
the PRIORITY frame - and thus does not return RST_STREAM, and
some implementations send GO_AWAY when receiving a
WINDOW_UPDATE frame with increment of 0. The vulnerability
takes advantage of a design flaw in the HTTP/2 protocol -
While HTTP/2 has a limit on the number of concurrently active
streams per connection (which is usually 100, and is set by
the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of
active streams is not counted correctly - when a stream is
reset, it is immediately considered not active, and thus
unaccounted for in the active streams counter. While the
protocol does not count those streams as active, the
server’s backend logic still processes and handles the
requests that were canceled. Thus, the attacker can exploit
this vulnerability to cause the server to handle an unbounded
number of concurrent streams from a client on the same
connection. The exploitation is very simple: the client
issues a request in a stream, and then sends the control
frame that causes the server to send a RST_STREAM. ### Attack
Flow For example, a possible attack scenario can be: 1.
Attacker opens an HTTP/2 connection to the server. 2.
Attacker sends HEADERS frame with END_STREAM flag on a new
stream X. 3. Attacker sends WINDOW_UPDATE for stream X with
flow-control window of 0. 4. The server receives the
WINDOW_UPDATE and immediately sends RST_STREAM for stream X
to the client (+ decreases the active streams counter by 1).
The attacker can repeat steps 2+3 as rapidly as it is
capable, since the active streams counter never exceeds 1 and
the attacker does not need to wait for the response from the
server. This leads to resource exhaustion and distributed
denial of service vulnerabilities with an impact of: CPU
overload and/or memory exhaustion (implementation dependent)
### Comparison to Rapid Reset The vulnerability takes
advantage of a design flow in the HTTP/2 protocol that was
also used in the Rapid Reset vulnerability (CVE-2023-44487)
which was exploited as a zero-day in the wild in August 2023
to October 2023, against multiple services and vendors. The
Rapid Reset vulnerability uses RST_STREAM frames sent from
the client, in order to create an unbounded amount of
concurrent streams - it was given a CVSS score of 7.5. Rapid
Reset was mostly mitigated by limiting the number/rate of
RST_STREAM sent from the client, which does not mitigate the
MadeYouReset attack - since it triggers the server to send a
RST_STREAM. ### Suggested Mitigations for MadeYouReset A
quick and easy mitigation will be to limit the number/rate of
RST_STREAMs sent from the server. It is also possible to
limit the number/rate of control frames sent by the client
(e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow
errors as a connection error. As mentioned in our previous
message, this is a protocol-level vulnerability that affects
multiple vendors and implementations. Given its broad impact,
it is the shared responsibility of all parties involved to
handle the disclosure process carefully and coordinate
mitigations effectively. If you have any questions, we will
be happy to clarify or schedule a Zoom call. Gal, Anat and
Yaniv.
HTTP Range header that triggers quadratic-time processing in
Starlette's
FileResponseRange parsing/merging logic. Thisenables CPU exhaustion per request, causing
denial‑of‑service for endpoints serving files (e.g.,
StaticFilesor any use ofFileResponse). ### DetailsStarlette parses multi-range requests in
FileResponse._parse_range_header(), then merges rangesusing an O(n^2) algorithm.
python # starlette/responses.py<br>_RANGE_PATTERN = re.compile(r"(\d*)-(\d*)") # vulnerable to<br>O(n^2) complexity ReDoS class FileResponse(Response):<br>@staticmethod def _parse_range_header(http_range: str,<br>file_size: int) -> list[tuple[int, int]]: ranges:<br>list[tuple[int, int]] = [] try: units, range_ =<br>http_range.split("=", 1) except ValueError: raise<br>MalformedRangeHeader() # [...] ranges = [ ( int(_[0]) if _[0]<br>else file_size - int(_[1]), int(_[1]) + 1 if _[0] and _[1]<br>and int(_[1]) < file_size else file_size, ) for _ in<br>_RANGE_PATTERN.findall(range_) # vulnerable if _ != ("", "")<br>]The parsing loop ofFileResponse._parse_range_header()uses the regularexpression which vulnerable to denial of service for its
O(n^2) complexity. A crafted
Rangeheader can maximize itscomplexity. The merge loop processes each input range by
scanning the entire result list, yielding quadratic behavior
with many disjoint ranges. A crafted Range header with many
small, non-overlapping ranges (or specially shaped numeric
substrings) maximizes comparisons. This affects any Starlette
application that uses: -
starlette.staticfiles.StaticFiles(internally returnsFileResponse) —starlette/staticfiles.py:178- Directstarlette.responses.FileResponseresponses ### PoCpython #!/usr/bin/env python3 import sys import time try:<br>import starlette from starlette.responses import FileResponse<br>except Exception as e: print(f"[ERROR] Failed to import<br>starlette: {e}") sys.exit(1) def build_payload(length: int)<br>-> str: """Build the Range header value body: '0' * num_zeros<br>+ '0-'""" return ("0" * length) + "a-" def test(header: str,<br>file_size: int) -> float: start = time.perf_counter() try:<br>FileResponse._parse_range_header(header, file_size) except<br>Exception: pass end = time.perf_counter() elapsed = end -<br>start return elapsed def run_once(num_zeros: int) -> None:<br>range_body = build_payload(num_zeros) header = "bytes=" +<br>range_body # Use a sufficiently large file_size so upper<br>bounds default to file size file_size = max(len(range_body) +<br>10, 1_000_000) print(f"[DEBUG] range_body length:<br>{len(range_body)} bytes") elapsed_time = test(header,<br>file_size) print(f"[DEBUG] elapsed time: {elapsed_time:.6f}<br>seconds\n") if __name__ == "__main__": print(f"[INFO]<br>Starlette Version: {starlette.__version__}") for n in [5000,<br>10000, 20000, 40000]: run_once(n) """ $ python3<br>poc_dos_range.py [INFO] Starlette Version: 0.48.0 [DEBUG]<br>range_body length: 5002 bytes [DEBUG] elapsed time: 0.053932<br>seconds [DEBUG] range_body length: 10002 bytes [DEBUG]<br>elapsed time: 0.209770 seconds [DEBUG] range_body length:<br>20002 bytes [DEBUG] elapsed time: 0.885296 seconds [DEBUG]<br>range_body length: 40002 bytes [DEBUG] elapsed time: 3.238832<br>seconds """### Impact Any Starlette app serving filesvia FileResponse or StaticFiles; frameworks built on
Starlette (e.g., FastAPI) are indirectly impacted when using
file-serving endpoints. Unauthenticated remote attackers can
exploit this via a single HTTP request with a crafted Range
header.
(greater than the default max spool
size)
starlettewill block the main thread to roll the file overto disk. This blocks the event thread which means we can't
accept new connections. ### Details Please see this
discussion for details:
Kludex/starlette#2927 (reply in thread).
In summary the following UploadFile code (copied from
here)
has a minor bug. Instead of just checking for
self._in_memorywe should also check if the additionalbytes will cause a rollover.
python @property def<br>_in_memory(self) -> bool: # check for<br>SpooledTemporaryFile._rolled rolled_to_disk =<br>getattr(self.file, "_rolled", True) return not rolled_to_disk<br>async def write(self, data: bytes) -> None: if self.size is<br>not None: self.size += len(data) if self._in_memory:<br>self.file.write(data) else: await<br>run_in_threadpool(self.file.write, data)I have alreadycreated a PR which fixes the problem:
Kludex/starlette#2962 ### PoC See the
discussion
here
for steps on how to reproduce. ### Impact To be honest, very
low and not many users will be impacted. Parsing large forms
is already CPU intensive so the additional IO block doesn't
slow down
starlettethat much on systems with modernHDDs/SSDs. If someone is running on tape they might see a
greater impact.
the processing time of some inputs scale non-linearly with
respect to the size of the certificate. This affects programs
which validate arbitrary certificate chains.
contains deeply nested literals can cause a panic due to
stack exhaustion.
nested structures can cause a panic due to stack exhaustion.
This is a follow-up to CVE-2022-30635.
nested expressions can cause a panic due to stack exhaustion.
ID may incorrectly satisfy a URI name constraint that applies
to the certificate chain. Certificates containing URIs are
not permitted in the web PKI, so this only affects users of
private PKIs which make use of URIs.
cross-domain redirect. For example, a request to a.com/
containing an Authorization header which is redirected to
b.com/ will not send that header to b.com. In the event that
the client received a subsequent same-domain redirect,
however, the sensitive headers would be restored. For
example, a chain of redirects from a.com/, to b.com/1, and
finally to b.com/2 would incorrectly send the Authorization
header to b.com/2.
assembly implementation of an internal function, a small
number of bits of secret scalars are leaked on the ppc64le
architecture. Due to the way this function is used, we do not
believe this leakage is enough to allow recovery of the
private key when P-256 is used in any well known protocols.
terminator in chunked data chunk-size lines. This can permit
request smuggling if a net/http server is used in conjunction
with a server that incorrectly accepts a bare LF as part of a
chunk-ext.
on cross-origin redirects potentially leaking sensitive
information.
one of the query methods) during a call to the Scan method of
the returned Rows can result in unexpected results if other
queries are being made in parallel. This can result in a race
condition that may overwrite the expected results with those
of another query, causing the call to Scan to return either
unexpected results from the other query or an error.
executables (rather than just directories), passing certain
strings to LookPath ("", ".", and ".."), can result in the
binaries listed in the PATH being unexpectedly returned.
components through repeated string concatenation. When
parsing large domain-literal components, this can cause
excessive CPU consumption.
contains attacker controlled information (the ALPN protocols
sent by the client) which is not escaped.
non-linearly with respect to the size of the input. This
affects programs which parse untrusted PEM inputs.
to be included in square brackets within the host component
of a URL. RFC 3986 permits IPv6 addresses to be included
within the host component, enclosed within square brackets.
For example: "http://[::1]/". IPv4 addresses and hostnames
must not appear within square brackets. Parse did not enforce
this requirement.
large amounts of memory, causing memory exhaustion.
number of cookies that can be parsed does not have a limit.
By sending a lot of very small cookies such as "a=;", an
attacker can make an HTTP server allocate a large amount of
structs, causing large memory consumption.
can cause programs to panic, due to a interface cast that
assumes they implement the Equal method. This affects
programs which validate arbitrary certificate chains.
sparse region data blocks in GNU tar pax 1.0 sparse files. A
maliciously-crafted archive containing a large number of
sparse regions can cause a Reader to read an unbounded amount
of data from the archive into memory. When reading from a
compressed source, a small compressed input can result in
large allocations.
through repeated string concatenation of lines. When the
number of lines in a response is large, this can cause
excessive CPU consumption.
backend to parse untrusted Protocol Buffers data containing
an arbitrary number of recursive groups, recursive
messages or a series of
SGROUPtags can be corrupted by exceeding the Python recursion
limit. Reporter: Alexis Challande, Trail of Bits Ecosystem
Security Team
[email protected]
Affected versions: This issue only affects the pure-Python
implementation
of protobuf-python backend. This is the implementation when
PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=pythonenvironmentvariable is set or the default when protobuf is used from
Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not
use pure-Python by default. This is a Python variant of a
previous issue affecting
protobuf-java.
### Severity This is a potential Denial of Service. Parsing
nested protobuf data creates unbounded recursions that can be
abused by an attacker. ### Proof of Concept For reproduction
details, please refer to the unit tests
decoder_test.py
and
message_test
### Remediation and Mitigation A mitigation is available now.
Please update to the latest available versions of the
following packages: * protobuf-python(4.25.8, 5.29.5, 6.31.1)
PackageIndexwas fixed in setuptools version 78.1.1 ### Details
def<br>_download_url(self, url, tmpdir): # Determine download<br>filename # name, _fragment = egg_info_for_url(url) if name:<br>while '..' in name: name = name.replace('..',<br>'.').replace('\\', '_') else: name = "__downloaded__" #<br>default if URL has no path contents if<br>name.endswith('.[egg.zip](http://egg.zip/)'): name =<br>name[:-4] # strip the extra .zip before download --> filename<br>= os.path.join(tmpdir, name)Here:https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/package_index.py#L810C1-L825C88
os.path.join()discards the first argumenttmpdirif thesecond begins with a slash or drive letter.
nameis derivedfrom a URL without sufficient sanitization. While there is
some attempt to sanitize by replacing instances of '..' with
'.', it is insufficient. ### Risk Assessment As easy_install
and package_index are deprecated, the exploitation surface is
reduced. However, it seems this could be exploited in a
similar fashion like
GHSA-r9hx-vwmv-q579, and as
described by POC 4 in
GHSA-cx63-2mw6-8hw5 report: via
malicious URLs present on the pages of a package index. ###
Impact An attacker would be allowed to write files to
arbitrary locations on the filesystem with the permissions of
the process running the Python code, which could escalate to
RCE depending on the context. ### References
https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5
pypa/setuptools#4946
package_indexmodule ofpypa/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.
You can merge this PR once the tests pass and the changes are reviewed.
Thank you for reviewing the update! 🚀