Search for packages
| purl | pkg:rpm/redhat/jenkins-2-plugins@4.15.1718879538-1?arch=el8 |
| Next non-vulnerable version | None. |
| Latest non-vulnerable version | None. |
| Risk | 10.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-3cnb-4rqk-zbez
Aliases: CVE-2024-23900 GHSA-cjgm-9vc9-56mx |
Path traversal vulnerability in Jenkins Matrix Project Plugin Jenkins Matrix Project Plugin 822.v01b_8c85d16d2 and earlier does not sanitize user-defined axis names of multi-configuration projects submitted through the `config.xml` REST API endpoint. This allows attackers with Item/Configure permission to create or replace any `config.xml` file on the Jenkins controller file system with content not controllable by the attackers. Matrix Project Plugin 822.824.v14451b_c0fd42 sanitizes user-defined axis names of Multi-configuration project. | There are no reported fixed by versions. |
|
VCID-5qhm-ase5-5qhy
Aliases: CVE-2024-22201 GHSA-rggv-cv7r-mw98 |
Connection leaking on idle timeout when TCP congested ### Impact If an HTTP/2 connection gets TCP congested, when an idle timeout occurs the HTTP/2 session is marked as closed, and then a GOAWAY frame is queued to be written. However it is not written because the connection is TCP congested. When another idle timeout period elapses, it is then supposed to hard close the connection, but it delegates to the HTTP/2 session which reports that it has already been closed so it does not attempt to hard close the connection. This leaves the connection in ESTABLISHED state (i.e. not closed), TCP congested, and idle. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The client may also be impacted (if the server does not read causing a TCP congestion), but the issue is more severe for servers. ### Patches Patched versions: * 9.4.54 * 10.0.20 * 11.0.20 * 12.0.6 ### Workarounds Disable HTTP/2 and HTTP/3 support until you can upgrade to a patched version of Jetty. HTTP/1.x is not affected. ### References * https://github.com/jetty/jetty.project/issues/11256. | There are no reported fixed by versions. |
|
VCID-6rup-vv6d-eqd8
Aliases: CVE-2024-23899 GHSA-vph5-2q33-7r9h |
Arbitrary file read vulnerability in Git server Plugin can lead to RCE Jenkins Git server Plugin uses the [args4j](https://github.com/kohsuke/args4j) library to parse command arguments and options on the Jenkins controller when processing Git commands received via SSH. This command parser has a feature that replaces an @ character followed by a file path in an argument with the file’s contents (`expandAtFiles`). This feature is enabled by default and Git server Plugin 99.va_0826a_b_cdfa_d and earlier does not disable it. This allows attackers with Overall/Read permission to read the first two lines of arbitrary files on the Jenkins controller file system using the default character encoding of the Jenkins controller process. See [SECURITY-3314](https://www.jenkins.io/security/advisory/2024-01-24/#SECURITY-3314) for further information about the potential impact of being able to read files on the Jenkins controller, as well as the [limitations for reading binary files](https://www.jenkins.io/security/advisory/2024-01-24/#binary-files-note). Note that for this issue, unlike SECURITY-3314, attackers need Overall/Read permission. ## Fix Description Git server Plugin 99.101.v720e86326c09 disables the command parser feature that replaces an @ character followed by a file path in an argument with the file’s contents for CLI commands. ## Workaround Navigate to Manage Jenkins » Security and ensure that the SSHD Port setting in the SSH Server section is set to Disable. This disables access to Git repositories hosted by Jenkins (and the Jenkins CLI) via SSH. | There are no reported fixed by versions. |
|
VCID-acdw-t3mm-wbhb
Aliases: CVE-2024-34145 GHSA-2g4q-9vm9-9fw4 |
Jenkins Script Security Plugin sandbox bypass vulnerability Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed. Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier: - Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts. - Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type. These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM. | There are no reported fixed by versions. |
|
VCID-f8ak-21d8-juff
Aliases: CVE-2024-24786 GHSA-8r3f-844c-mc37 |
Golang protojson.Unmarshal function infinite loop when unmarshaling certain forms of invalid JSON The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set. | There are no reported fixed by versions. |
|
VCID-jzn6-bzzf-nugp
Aliases: CVE-2023-48795 GHSA-45x7-px36-x8w8 |
Improper Validation of Integrity Check Value The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust. | There are no reported fixed by versions. |
|
VCID-qnbx-c635-hqer
Aliases: CVE-2024-34144 GHSA-v63g-v339-2673 |
Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed. Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier: - Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts. - Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type. These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM. - These issues are caused by an incomplete fix of [SECURITY-2824](https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2824%20(1)). Script Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox: - Calls to to other constructors using this are now intercepted by the sandbox. - Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls. | There are no reported fixed by versions. |
|
VCID-s4j7-r6m7-tyey
Aliases: CVE-2024-28149 GHSA-8vcg-v7g4-3vr7 |
Jenkins HTML Publisher Plugin does not properly sanitize input Jenkins HTML Publisher Plugin 1.16 through 1.32 (both inclusive) does not properly sanitize input, allowing attackers with Item/Configure permission to implement cross-site scripting (XSS) attacks and to determine whether a path on the Jenkins controller file system exists. | There are no reported fixed by versions. |
|
VCID-tsgr-5mwt-jkeh
Aliases: CVE-2024-21626 GHSA-xr7r-f8xq-vfvv |
runc vulnerable to container breakout through process.cwd trickery and leaked fds ### 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 `pivot_root(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, `PR_SET_DUMPABLE` protections no longer apply and the attacker can open `/proc/$exec_pid/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 `O_CLOEXEC` 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 `O_CLOEXEC` 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](#Patches) and make sure they at least add a `getcwd() != ENOENT` check as well as consider whether `close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC)` 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 `O_CLOEXEC` 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 `pivot_root`'d into and so ends up as a in-root path thanks to `chroot_fs_refs`). In addition, no care is taken to make sure all non-stdio files are `O_CLOEXEC` 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 `close_range(...)` (they do have RAII-like `__do_fclose` 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 `CLOSE_RANGE_CLOEXEC` 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). | There are no reported fixed by versions. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||