A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing.

With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection.

This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2.

The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.

An issue was discovered in Mbed TLS 2.18.0 through 2.28.x before 2.28.8 and 3.x before 3.6.0 and Mbed Crypto. The PSA Crypto API mishandles shared memory.

Mbed TLS 2.x before 2.28.5 and 3.x before 3.5.0 has a Buffer Overflow.

libexpat could allow a remote attacker to obtain sensitive information, caused by improper handling of XML external entity (XXE) declarations by the XMLExternalEntityParserCreate function. By using a specially crafted XML content, a remote attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.

Impact

In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b").

Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R vectors, despite attacks 2 and 3b requiring far more minimal user interaction (just reasonable runc exec operations on a container the attacker has access to). In any case, all four attacks can lead to full control of the host system.

Attack 1: process.cwd "mis-configuration"

In runc 1.1.11 and earlier, several file descriptors were inadvertently leaked internally within runc into runc init, including a handle to the host's /sys/fs/cgroup (this leak was added in v1.0.0-rc93). If the container was configured to have process.cwd set to /proc/self/fd/7/ (the actual fd can change depending on file opening order in runc), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem. This alone is not an exploit against runc, however a malicious image could make any innocuous-looking non-/ path a symlink to /proc/self/fd/7/ and thus trick a user into starting a container whose binary has access to the host filesystem.

Furthermore, prior to runc 1.1.12, runc also did not verify that the final working directory was inside the container's mount namespace after calling chdir(2) (as we have already joined the container namespace, it was incorrectly assumed there would be no way to chdir outside the container after pivotroot(2)).

The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (8.2, high severity).

Note that this attack requires a privileged user to be tricked into running a malicious container image. It should be noted that when using higher-level runtimes (such as Docker or Kubernetes), this exploit can be considered critical as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using ONBUILD in the case of Docker).

Attack 2: runc exec container breakout

(This is a modification of attack 1, constructed to allow for a process inside a container to break out.)

The same fd leak and lack of verification of the working directory in attack 1 also apply to runc exec. If a malicious process inside the container knows that some administrative process will call runc exec with the --cwd argument and a given path, in most cases they can replace that path with a symlink to /proc/self/fd/7/. Once the container process has executed the container binary, PRSETDUMPABLE protections no longer apply and the attacker can open /proc/$execpid/cwd to get access to the host filesystem.

runc exec defaults to a cwd of / (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use --cwd and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the execve will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the runc exec is executing).

The CVSS score for this attack is CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N (7.2, high severity).

Attacks 3a and 3b: process.args host binary overwrite attack

(These are modifications of attacks 1 and 2, constructed to overwrite a host binary by using execve to bring a magic-link reference into the container.)

Attacks 1 and 2 can be adapted to overwrite a host binary by using a path like /proc/self/fd/7/../../../bin/bash as the process.args binary argument, causing a host binary to be executed by a container process. The /proc/$pid/exe handle can then be used to overwrite the host binary, as seen in CVE-2019-5736 (note that the same #! trick can be used to avoid detection as an attacker). As the overwritten binary could be something like /bin/bash, as soon as a privileged user executes the target binary on the host, the attacker can pivot to gain full access to the host.

For the purposes of CVSS scoring:

Attack 3a is attack 1 but adapted to overwrite a host binary, where a malicious image is set up to execute /proc/self/fd/7/../../../bin/bash and run a shell script that overwrites /proc/self/exe, overwriting the host copy of /bin/bash. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6, high severity). Attack 3b is attack 2 but adapted to overwrite a host binary, where the malicious container process overwrites all of the possible runc exec target binaries inside the container (such as /bin/bash) such that a host target binary is executed and then the container process opens /proc/$pid/exe to get access to the host binary and overwrite it. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H (8.2, high severity).

As mentioned in attack 1, while 3b is scored lower it is more dangerous in practice as it doesn't require a user to run a malicious image.

Patches runc 1.1.12 has been released, and includes patches for this issue. Note that there are four separate fixes applied:

Checking that the working directory is actually inside the container by checking whether os.Getwd returns ENOENT (Linux provides a way of detecting if cwd is outside the current namespace root). This explicitly blocks runc from executing a container process when inside a non-container path and thus eliminates attacks 1 and 2 even in the case of fd leaks. Close all internal runc file descriptors in the final stage of runc init, right before execve. This ensures that internal file descriptors cannot be used as an argument to execve and thus eliminates attacks 3a and 3b, even in the case of fd leaks. This requires hooking into some Go runtime internals to make sure we don't close critical Go internal file descriptors. Fixing the specific fd leaks that made these bug exploitable (mark /sys/fs/cgroup as OCLOEXEC and backport a fix for some os.File leaks). In order to protect against future runc init file descriptor leaks, mark all non-stdio files as OCLOEXEC before executing runc init.

Other Runtimes

We have discovered that several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature. We recommend other container runtime authors look at our patches and make sure they at least add a getcwd() != ENOENT check as well as consider whether closerange(3, UINTMAX, CLOSERANGECLOEXEC) before executing their equivalent of runc init is appropriate.

crun 1.12 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell), but no care is taken to make sure all non-stdio files are OCLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to crun are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of crun can lead to these attacks becoming exploitable. youki 0.3.1 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell) however this appears to be pure luck. youki does leak a directory file descriptor from the host mount namespace, but it just so happens that the directory is the rootfs of the container (which then gets pivotroot'd into and so ends up as a in-root path thanks to chrootfsrefs). In addition, no care is taken to make sure all non-stdio files are OCLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to youki are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of youki can lead to these attacks becoming exploitable. LXC 5.0.3 does not appear to leak any useful file descriptors, and they have comments noting the importance of not leaking file descriptors in lxc-attach. However, they don't seem to have any proactive protection against file descriptor leaks at the point of chdir such as using closerange(...) (they do have RAII-like dofclose closers but those don't necessarily stop all leaks in this context) nor do they have any check after chdir(2) to ensure the working directory is inside the container. Unfortunately it seems they cannot use CLOSERANGECLOEXEC because they don't need to re-exec themselves.

Workarounds For attacks 1 and 2, only permit containers (and runc exec) to use a process.cwd of /. It is not possible for / to be replaced with a symlink (the path is resolved from within the container's mount namespace, and you cannot change the root of a mount namespace or an fs root to a symlink).

For attacks 1 and 3a, only permit users to run trusted images.

For attack 3b, there is no practical workaround other than never using runc exec because any binary you try to execute with runc exec could end up being a malicious binary target.

See Also https://www.cve.org/CVERecord?id=CVE-2024-21626 https://github.com/opencontainers/runc/releases/tag/v1.1.12 The runc 1.1.12 merge commit https://github.com/opencontainers/runc/commit/a9833ff391a71b30069a6c3f816db113379a4346, which contains the following security patches: https://github.com/opencontainers/runc/commit/506552a88bd3455e80a9b3829568e94ec0160309 https://github.com/opencontainers/runc/commit/0994249a5ec4e363bfcf9af58a87a722e9a3a31b https://github.com/opencontainers/runc/commit/fbe3eed1e568a376f371d2ced1b4ac16b7d7adde https://github.com/opencontainers/runc/commit/284ba3057e428f8d6c7afcc3b0ac752e525957df https://github.com/opencontainers/runc/commit/b6633f48a8c970433737b9be5bfe4f25d58a5aa7 https://github.com/opencontainers/runc/commit/683ad2ff3b01fb142ece7a8b3829de17150cf688 https://github.com/opencontainers/runc/commit/e9665f4d606b64bf9c4652ab2510da368bfbd951

Credits

Thanks to Rory McNamara from Snyk for discovering and disclosing the original vulnerability (attack 1) to Docker, @lifubang from acmcoder for discovering how to adapt the attack to overwrite host binaries (attack 3a), and Aleksa Sarai from SUSE for discovering how to adapt the attacks to work as container breakouts using runc exec (attacks 2 and 3b).

A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftsetpipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.

Based on patch from Florian Westphal.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: Fix potential data-race in nftobjtypeget()

nftunregisterobj() can concurrent with nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.

Use listforeachentryrcu() to iterate over nftablesobjects list in nftobjtypeget(), and use rcureadlock() in the caller nftobjtypeget() to protect the entire type query process.

Accounts. The issue was addressed with improved checks.

Accounts. The issue was addressed with improved checks.

Accounts. The issue was addressed with improved checks.

A use-after-free vulnerability in the Linux kernel's netfilter: nftables component can be exploited to achieve local privilege escalation.

The nftverdictinit() function allows positive values as drop error within the hook verdict, and hence the nfhookslow() function can cause a double free vulnerability when NFDROP is issued with a drop error which resembles NFACCEPT.

We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

A race condition was found in the GSM 0710 tty multiplexor (drivers/tty/ngsm.c) in the Linux kernel. The flaw occurs when two threads execute the GSMIOCSETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled and leads to a use-after-free on a struct gsmdlci while restarting the gsm mux. A local unprivileged user could use this vulnerability to escalate their privileges on the system.

ZDI Security Advisory: https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527

Upstream fix: https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3

In the Linux kernel, the following vulnerability has been resolved:

firewire: nosy: ensure userlength is taken into account when fetching packet contents

Ensure that packetbufferget respects the userlength provided. If the length of the head packet exceeds the userlength, packetbufferget will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: once more fix the call oder in amdgputtmmove() v2

This reverts drm/amdgpu: fix ftrace event amdgpubomove always move on same heap. The basic problem here is that after the move the old location is simply not available any more.

Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well.

Also rework the statistic handling so that we don't update the eviction counter before the move.

v2: add missing NULL check

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix use-after-free bugs caused by scosocktimeout

The Linux kernel CVE team has assigned CVE-2024-27398 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051355-CVE-2024-27398-08ef@gregkh/T

In the Linux kernel, the following vulnerability has been resolved:

netfilter: brnetfilter: skip conntrack input hook for promisc packets

For historical reasons, when bridge device is in promisc mode, packets that are directed to the taps follow bridge input hook path. This patch adds a workaround to reset conntrack for these packets.

Jianbo Liu reports warning splats in their test infrastructure where cloned packets reach the brnetfilter input hook to confirm the conntrack object.

Scratch one bit from BRINPUTSKBCB to annotate that this packet has reached the input hook because it is passed up to the bridge device to reach the taps.

[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/brnetfilterhooks.c:616 brnflocalin+0x157/0x180 [brnetfilter] [ 57.572749] Modules linked in: xtMASQUERADE nfconntracknetlink nfnetlink iptablenat xtaddrtype xtconntrack nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportisc si ibumad rdmacm ibipoib iwcm ibcm mlx5ib ibuverbs ibcore mlx5ctl mlx5core [ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19 [ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 57.576662] RIP: 0010:brnflocalin+0x157/0x180 [brnetfilter] [ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1 [ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202 [ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000 [ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000 [ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003 [ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000 [ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800 [ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000 [ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0 [ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 57.585440] Call Trace: [ 57.585721] <IRQ> [ 57.585976] ? warn+0x7d/0x130 [ 57.586323] ? brnflocalin+0x157/0x180 [brnetfilter] [ 57.586811] ? reportbug+0xf1/0x1c0 [ 57.587177] ? handlebug+0x3f/0x70 [ 57.587539] ? excinvalidop+0x13/0x60 [ 57.587929] ? asmexcinvalidop+0x16/0x20 [ 57.588336] ? brnflocalin+0x157/0x180 [brnetfilter] [ 57.588825] nfhookslow+0x3d/0xd0 [ 57.589188] ? brhandlevlan+0x4b/0x110 [ 57.589579] brpassframeup+0xfc/0x150 [ 57.589970] ? brportflagschange+0x40/0x40 [ 57.590396] brhandleframefinish+0x346/0x5e0 [ 57.590837] ? iptdotable+0x32e/0x430 [ 57.591221] ? brhandlelocalfinish+0x20/0x20 [ 57.591656] brnfhookthresh+0x4b/0xf0 [brnetfilter] [ 57.592286] ? brhandlelocalfinish+0x20/0x20 [ 57.592802] brnfpreroutingfinish+0x178/0x480 [brnetfilter] [ 57.593348] ? brhandlelocalfinish+0x20/0x20 [ 57.593782] ? nfnatipv4prerouting+0x25/0x60 [nfnat] [ 57.594279] brnfprerouting+0x24c/0x550 [brnetfilter] [ 57.594780] ? brnfhookthresh+0xf0/0xf0 [brnetfilter] [ 57.595280] brhandleframe+0x1f3/0x3d0 [ 57.595676] ? brhandlelocalfinish+0x20/0x20 [ 57.596118] ? brhandleframefinish+0x5e0/0x5e0 [ 57.596566] netifreceiveskbcore+0x25b/0xfc0 [ 57.597017] ? napibuildskb+0x37/0x40 [ 57.597418] netifreceiveskblistcore+0xfb/0x220

In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: validate pppoe header

Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: restore set elements when delete set fails

From abort path, nftmapelemactivate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones).

This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements.

Toggle next generation bit for elements when delete set command is invoked and call nftclear() from .activate (abort) path to restore the next generation bit.

The splat below shows an object in mappings memleak:

[43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nftables.h:1237 nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [...] [43929.458014] RIP: 0010:nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] <TASK> [43929.458121] ? warn+0x9f/0x1a0 [43929.458127] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458188] ? reportbug+0x1b1/0x1e0 [43929.458196] ? handlebug+0x3c/0x70 [43929.458200] ? excinvalidop+0x17/0x40 [43929.458211] ? nftsetelemdatadeactivate+0xd7/0xf0 [nftables] [43929.458271] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458332] nftmapelemdeactivate+0x24/0x30 [nftables] [43929.458392] nftrhashwalk+0xdd/0x180 [nftables] [43929.458453] ? pfxnftrhashwalk+0x10/0x10 [nftables] [43929.458512] ? rbinsertcolor+0x2e/0x280 [43929.458520] nftmapdeactivate+0xdc/0x1e0 [nftables] [43929.458582] ? pfxnftmapdeactivate+0x10/0x10 [nftables] [43929.458642] ? pfxnftmapelemdeactivate+0x10/0x10 [nftables] [43929.458701] ? rcureadunlock+0x46/0x70 [43929.458709] nftdelset+0xff/0x110 [nftables] [43929.458769] nftflushtable+0x16f/0x460 [nftables] [43929.458830] nftablesdeltable+0x501/0x580 [nftables]

In the Linux kernel, the following vulnerability has been resolved:

speakup: Avoid crash on very long word

In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: validate the parameters of bo mapping operations more clearly

The Linux kernel CVE team has assigned CVE-2024-26922 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024042317-CVE-2024-26922-896d@gregkh/T

latchset jose through version 11 allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.

Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.

Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.

Out-of-bounds Write vulnerability in Apache Commons Configuration.

Affected versions:

- Apache Commons Configuration 2.0 before 2.10.1

References:

https://www.cve.org/CVERecord?id=CVE-2024-29131 https://issues.apache.org/jira/browse/CONFIGURATION-840

Summary Improperly configuring static resource resolution in aiohttp when used as a web server can result in the unauthorized reading of arbitrary files on the system.

Details When using aiohttp as a web server and configuring static routes, it is necessary to specify the root path for static files. Additionally, the option 'followsymlinks' can be used to determine whether to follow symbolic links outside the static root directory. When 'followsymlinks' is set to True, there is no validation to check if a given file path is within the root directory.This can lead to directory traversal vulnerabilities, resulting in unauthorized access to arbitrary files on the system, even when symlinks are not present.

i.e. An application is only vulnerable with setup code like: app.router.addroutes([ web.static("/static", "static/", followsymlinks=True), # Remove followsymlinks to avoid the vulnerability ])

Impact This is a directory traversal vulnerability with CWE ID 22. When using aiohttp as a web server and enabling static resource resolution with followsymlinks set to True, it can lead to this vulnerability. This vulnerability has been present since the introduction of the followsymlinks parameter.

Workaround Even if upgrading to a patched version of aiohttp, we recommend following these steps regardless.

If using followsymlinks=True outside of a restricted local development environment, disable the option immediately. This option is NOT needed to follow symlinks which point to a location within the static root directory, it is only intended to allow a symlink to break out of the static directory. Even with this CVE fixed, there is still a substantial risk of misconfiguration when using this option on a server that accepts requests from remote users.

Additionally, aiohttp has always recommended using a reverse proxy server (such as nginx) to handle static resources and not to use these static resources in aiohttp for production environments. Doing so also protects against this vulnerability, and is why we expect the number of affected users to be very low.

-----

Patch: https://github.com/aio-libs/aiohttp/pull/8079/files

An off-by-one heap-based buffer overflow was found in the vsysloginternal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when these functions are called with a message bigger than INTMAX bytes, leading to an incorrect calculation of the buffer size to store the message, resulting in an application crash. This issue affects glibc 2.37 and newer.

A heap-based buffer overflow was found in the vsysloginternal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when the openlog function was not called, or called with the ident argument set to NULL, and the program name (the basename of argv[0]) is bigger than 1024 bytes, resulting in an application crash or local privilege escalation. This issue affects glibc 2.36 and newer.

A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBCTUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBCTUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.

Cookie HTTP header isn't stripped on cross-origin redirects

A buffer overflow was found in Shim in the 32-bit system. The overflow happens due to an addition operation involving a user-controlled value parsed from the PE binary being used by Shim. This value is further used for memory allocation operations, leading to a heap-based buffer overflow. This flaw causes memory corruption and can lead to a crash or data integrity issues during the boot phase.