Last updated 24 July 2024

This affects the package thenify before 3.3.1. The name argument provided to the package can be controlled by users without any sanitization, and this is provided to the eval function without any sanitization.

A symlink following vulnerability was found in the ABRT post-create event handler scripts in /etc/libreport/events.d/abrtevent.conf. Event scripts write output files using shell redirections (e.g., "printf ... > $DUMPDIR/varlogmessages") which use open() with OWRONLY|OCREAT|OTRUNC without the ONOFOLLOW flag. If the target file is replaced with a symlink, the shell process (running as root in the abrthandleeventt SELinux domain, which is effectively unconfined) follows the symlink and writes content to the symlink target. In contrast, ddsavetext (used by SetElement) correctly uses ONOFOLLOW. An attacker who has gained filesystem control of the dump directory can replace output files with symlinks pointing to sensitive system files such as /var/spool/cron/root.

A content injection vulnerability was found in the ABRT post-create event handler scripts in libreport. The event script queries the systemd journal for log entries matching the crashed process and writes the results to files in the dump directory without sanitizing embedded control characters. A local user can inject arbitrary content into the journal output by embedding newline characters in syslog messages, controlling the content that root writes to dump directory files.

Last updated 24 July 2024

Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1376.

A path traversal vulnerability exists in curl <8.0.0 SFTP implementation causes the tilde (~) character to be wrongly replaced when used as a prefix in the first path element in addition to its intended use as the first element to indicate a path relative to the user's home directory. Attackers can exploit this flaw to bypass filtering or execute arbitrary code by crafting a path like /~2/foo while accessing a server with a specific user.

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

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 closing HTTP/2 server connection could hang forever waiting for a clean shutdown that was preempted by a subsequent fatal error. This failure mode could be exploited to cause a denial of service.

References: https://go.dev/issue/54658 https://groups.google.com/g/golang-announce/c/x49AQzIVX-s/m/0tgO0pjiBQAJ

Upstream Commits: Master: https://github.com/golang/go/commit/29af494fca8a25d7d46276f6d4835c4dcd09e47d Branch.go1.18 : https://github.com/golang/go/commit/5bc9106458fc07851ac324a4157132a91b1f3479 Branch.go1.19 : https://github.com/golang/go/commit/9cfe4e258b1c9d4a04a42539c21c7bdb2e227824

A flaw was found in golang encoding/xml. When calling Decoder, Skip while parsing a deeply nested XML document, a panic can occur due to stack exhaustion and allows an attacker to impact system availability.

A flaw was found in the Go encoding/binary package. Certain invalid inputs to the ReadUvarint or the ReadVarint causes those functions to read an unlimited number of bytes from the ByteReader argument before returning an error. This flaw possibly leads to processing more input than expected. The highest threat from this vulnerability is to system availability.

The Verify function in crypto/dsa/dsa.go in Go before 1.5.4 and 1.6.x before 1.6.1 does not properly check parameters passed to the big integer library, which might allow remote attackers to cause a denial of service (infinite loop) via a crafted public key to a program that uses HTTPS client certificates or SSH server libraries.

A flaw was found Go's net/http package. Servers using ReverseProxy from net/http in the Go standard library are vulnerable to a data race that results in a denial of service. The highest threat from this vulnerability is to system availability.

A flaw detected in golang: crypto/elliptic, in which P-224 keys as generated can return incorrect inputs, reducing the strength of the cryptography. The highest threat from this vulnerability is confidentiality and integrity.

Golang Go could allow a remote attacker to execute arbitrary code on the system, caused by a flaw when running "go get" on a malicious module. By sending a specially crafted request using linker flags, an attacker could exploit this vulnerability to execute arbitrary code on the system.

A flaw was found in the math/big package of Go's standard library that causes a denial of service. Applications written in Go that use math/big via cryptographic packages, including crypto/rsa and crypto/x509, are vulnerable and can potentially cause panic via a crafted certificate chain. The highest threat from this vulnerability is to system availability.

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.

A heap-based buffer overflow vulnerability was found in Samba within the GSSAPI unwrapdes() and unwrapdes3() routines of Heimdal. The DES and Triple-DES decryption routines in the Heimdal GSSAPI library allow a length-limited write buffer overflow on malloc() allocated memory when presented with a maliciously small packet. This flaw allows a remote user to send specially crafted malicious data to the application, possibly resulting in a denial of service (DoS) attack.

drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release.

An out-of-bounds write vulnerability exists in the JPEG2000Codec::DecodeByStreamsCommon functionality of Mathieu Malaterre Grassroot DICOM 3.0.23. A specially crafted DICOM file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

A flaw was found in golang. Extraneous zero characters at the beginning of an IP address octet are not properly considered which could allow an attacker to bypass IP-based access controls. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Dominic Scheirlinck of VendHQ reports:

Many software projects and vendors have implemented support for the “Proxy” request header in their respective CGI implementations and languages by creating the “HTTPPROXY” environmental variable based on the header value. When this variable is used (in many cases automatically by various HTTP client libraries) any outgoing requests generated in turn from the attackers original request can be redirected to an attacker controlled proxy. This allows attackers to view potentially sensitive information, reply with malformed data, or to hold connections open causing a potential denial of service.

The Go programming language can automatically populate the HTTPPROXY environmental variable with a user supplied "Proxy" header.

Golang Go could allow a local authenticated attacker to gain elevated privileges on the system, caused by a flaw when a binary is run with the setuid/setgid bits. By sending a specially crafted request, an authenticated attacker could exploit this vulnerability to gain elevated privileges. to read or write contents of the registers.

As announced by Go upstream on 2019-10-17: Invalid DSA public keys can cause a panic in dsa.Verify. In particular, using crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic, even if the certificates don’t chain to a trusted root. The chain can be delivered via a crypto/tls connection to a client, or to a server that accepts and verifies client certificates. net/http clients can be made to crash by an HTTPS server, while net/http servers that accept client certificates will recover the panic and are unaffected.

Moreover, an application might crash invoking crypto/x509.(CertificateRequest) CheckSignature on an X.509 certificate request, parsing a golang.org/x/crypto/openpgp Entity, or during a golang.org/x/crypto/otr conversation. Finally, a golang.org/x/crypto/ssh client can panic due to a malformed host key, while a server could panic if either PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts a certificate with a malformed public key.

Upstream bug: https://github.com/golang/go/issues/34960

A flaw was found in the Go standard library packages before upstream versions 1.15 and 1.14.8. Both the net/http/cgi and net/http/fcgi packages use a default Content-Type response header value of "text/html", rather than "text/plain". This flaw allows an attacker to exploit this issue in applications using these packages by uploading crafted files, allowing a Cross-site Scripting attack (XSS). The highest threat from this vulnerability is to confidentiality and integrity.