Impact

Since Requests v2.3.0, Requests has been vulnerable to potentially leaking Proxy-Authorization headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how rebuildproxies is used to recompute and reattach the Proxy-Authorization header to requests when redirected. Note this behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080).

Current vulnerable behavior(s):

1. HTTP → HTTPS: leak 2. HTTPS → HTTP: no leak 3. HTTPS → HTTPS: leak 4. HTTP → HTTP: no leak

For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.

The reason this currently works for HTTPS connections in Requests is the Proxy-Authorization header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with proxymanagerfor. This will compute the required proxy headers in proxyheaders and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.

Patches Starting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.

For users with custom adapters, this may be potentially breaking if you were already working around this behavior. The previous functionality of rebuildproxies doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.

Workarounds For users who are not able to update Requests immediately, there is one potential workaround.

You may disable redirects by setting allowredirects to False on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination. import requests r = requests.get('http://github.com/', allowredirects=False)

Credits

This vulnerability was discovered and disclosed by the following individuals.

Dennis Brinkrolf, Haxolot (https://haxolot.com/) Tobias Funke, (tobiasfunke93@gmail.com)

The Linux Kernel lockdown mode for kernel versions starting on 6.12 and above for Fedora Linux has the lockdown mode disabled without any warning. This may allow an attacker to gain access to sensitive information such kernel memory mappings, I/O ports, BPF and kprobes. Additionally unsigned modules can be loaded, leading to execution of untrusted code breaking breaking any Secure Boot protection. This vulnerability affects only Fedora Linux.

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has been fixed in version 1.19.1.

Thanks for the reply Alex,

I didn't include that option because I ran into an issue that I couldn't find the root cause for. Specifically on Fedora, a dnf upgrade resulted in the mask disappearing. I could find some complaints with Fedora version upgrades, but couldn't find anything on package upgrade.

As I don't have access to the RedHat support portal I decided to exclude it out of caution.

It looked like there was nothing in /usr/lib/systemd/system-preset for sshd-vsock.socket that I found, and those should respect the mask for sshd-vsock.socket and wouldn't remove the /etc/systemd/system/sshd-vsock.socket symlink as I understand it.

I think that because it doesn't show up in busctl --activatable, and no packages I can find "Wants" sshd-vsock.socket explicitly that would probably work.

I just tried a fresh install of Fedora Linux 42 workstation and didn't experience the unintended unmasking with a dnf upgrade. That was reliable a few weeks ago. Maybe I just was unlucky with a package that was fixed?

Either way I think it is an option for people who use configuration management tools that can periodically check sshd-vsock.socket is still disabled.

Also for normal systemd services that need isolation from the vsock bridge you can use:

RestrictAddressFamilies=none # disable all af families RestrictAddressFamilies=AFINET # only AFINET RestrictAddressFamilies=~AFVSOCK # not AFVSOCK

The L4 bridge problem will be harder for projects that use CRI's that are not containerd like the k8s/podman/crun/runc.

If anyone on here is involved with them, or sandboxing tools like bubblewrap etc... Filtering address family 40 will still be required by default to have any real intra-container/pod/process network isolation on a node.

Thanks,

Greg

On Tue, Dec 30, 2025 at 12:12 PM <wish42offcl98 () posteo org> wrote: I have searched for that - instead of blacklisting the vsock module, I did myself two measures: - systemctl mask --now sshd-unix-local.socket to kill and mask the sshd unix socket created by that generator, - systemctl mask sshd-vsock.socket to mask the sshd vsock created by that generator (use --now if the socket has started or use systemctl stop... ).

Though, vsock untested but I found that source mentioning that socket. https://linux-audit.com/system-administration/commands/systemd-analyze/ Masking the sockets should stop them from starting again.

The vsock kernel module should not be blacklisted if some hypervisor features are required: https://libvirt.org/ssh-proxy.html https://wiki.qemu.org/Features/VirtioVsock

Greetings Alex

On 12/29/25 05:11, Jacob Bachmeyer wrote: On 12/27/25 21:46, Greg Dahlman wrote: [...]

Systemd v256 change - When the openssh-server package is installed on a VM with vsock support, systemd now automatically starts an sshd instance that listens on the afvsock socket in the global network namespace without any manual configuration. Obvious question: what manual configuration is required to kill that listener?

-- Jacob

A vulnerability was found in the avahi library. This flaw allows an unprivileged user to make a dbus call, causing the avahi daemon to crash.

On 2025-11-02 02:26:31 +0100 (+0100), Solar Designer wrote: [...] [...]

-- Jeremy Stanley

Fedora Repository 3.8.x includes a service account (fedoraIntCallUser) with default credentials and privileges to read read local files by manipulating datastreams. Fedora Repository 3.8.1 was released on 2015-06-11 and is no longer maintained. Migrate to a currently supported version (6.5.1 as of 2025-01-23).

Fedora Repository 3.8.1 allows path traversal when extracting uploaded archives ("Zip Slip"). A remote, authenticated attacker can upload a specially crafted archive that will extract an arbitrary JSP file to a location that can be executed by an unauthenticated GET request. Fedora Repository 3.8.1 was released on 2015-06-11 and is no longer maintained. Migrate to a currently supported version (6.5.1 as of 2025-01-23).

The Fedora Secure Boot CA certificate shipped with shim in Fedora was expired which could lead to old or invalid signed boot components being loaded.

The Fedora Secure Boot CA certificate shipped with shim-x64 in Fedora 38 was expired which could lead to old or invalid signed boot components being loaded.

Qualys Security Advisory

Local information disclosure in apport and systemd-coredump (CVE-2025-5054 and CVE-2025-4598)

======================================================================== Contents ========================================================================

Summary Mitigation Local information disclosure in apport (CVE-2025-5054) - Background - Analysis - Proof of concept Local information disclosure in systemd-coredump (CVE-2025-4598) - Background - Analysis - Proof of concept Acknowledgments Timeline

======================================================================== Summary ========================================================================

We discovered a vulnerability in apport (Ubuntu's core-dump handler), and a similar vulnerability in systemd-coredump (which is the default core-dump handler on Red Hat Enterprise Linux 9 and Fedora for example): a race condition that allows a local attacker to crash a SUID program and gain read access to the resulting core dump (by quickly replacing the crashed SUID process with another process, before its /proc/pid/ files are analyzed by the vulnerable core-dump handler).

We developed two proofs of concepts for these vulnerabilities (one for Ubuntu 24.04, and one for Fedora 40 and 41, but other distributions are probably also vulnerable and exploitable): they allow a local attacker to obtain the contents of /etc/shadow (password hashes) from the core dump of a crashed unixchkpwd process (unixchkpwd is a SUID or SGID program that is installed by default on most Linux distributions).

Last-minute update: while working on these vulnerabilities, we eventually realized that systemd-coredump does not specify %d (the kernel's per-process "dumpable" flag) in /proc/sys/kernel/corepattern; consequently a local attacker can crash (with kill(SIGSEGV) for example) root daemons that fork() and setuid() to the attacker's uid, gain read access to the resulting core dumps, and therefore to the root daemons' memory. For example, we wrote a trivial proof of concept that dumps the memory of OpenSSH's sshd-session, systemd's sd-pam, and the cron daemon, and obtained secret information such as half of sshd's private ed25519 host key, password hashes from /etc/shadow, other users' crontabs, ASLR addresses, stack canaries. This second attack (against root daemons) is powerful, different from the first attack (against SUID programs), and can certainly be further improved; and other secrets can certainly be obtained from other daemons, but this is left as an exercise for the interested reader.

The fix for these vulnerabilities is twofold:

- always take account of the kernel's per-process "dumpable" flag (the %d specifier), in every code path, to decide whether a non-root user should be given read access to a core dump or not;

- use the new %F specifier in /proc/sys/kernel/corepattern (a pidfd to the crashed process), which was implemented during this coordinated vulnerability disclosure, to detect whether the crashed process was replaced or not with another process, before its analysis; for more information:

https://lore.kernel.org/all/20250414-work-coredump-v2-0-685bf231f828 () kernel org/

======================================================================== Mitigation ========================================================================

To mitigate these vulnerabilities, /proc/sys/fs/suiddumpable can be set to 0 (SUIDDUMPDISABLE, "No setuid dumping"). This prevents all SUID programs and root daemons that drop privileges from being analyzed in case of a crash, but it can act as a temporary fix if the vulnerable core-dump handler itself cannot be patched immediately.

======================================================================== Local information disclosure in apport (CVE-2025-5054) ========================================================================

------------------------------------------------------------------------ Background ------------------------------------------------------------------------

After our discovery of three bypasses in Ubuntu's unprivileged user namespace restrictions, we decided to look for a real-world example of a vulnerability that requires a user namespace with full capabilities. One perfectly obvious example would be a kernel vulnerability that requires CAPSYSADMIN or CAPNETADMIN, but finding and exploiting such a kernel vulnerability would most likely take us months, so we decided to look for a simple userland vulnerability instead.

One target that immediately came to mind is apport, Ubuntu's core-dump handler, because it suffered from multiple vulnerabilities related to namespaces (containers) in the past; for example, the following excellent write-ups by Tavis Ormandy and Sander Bos:

- CVE-2015-1318: https://www.openwall.com/lists/oss-security/2015/04/14/4 - CVE-2017-14180: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1726372 - CVE-2019-11483: https://bugs.launchpad.net/apport/+bug/1839420

But as soon as we started to read apport's source code, we realized that it has been considerably hardened over the years:

- The most common attack vector against apport, which consisted in tricking apport into dumping an attacker-controlled core file into a root-owned directory such as /etc/sudoers.d/ or /etc/logrotate.d/, has been completely eradicated: apport now dumps all core files into a hard-coded directory (/var/lib/apport/coredump/ by default).

- The race condition that allows a local attacker to replace a crashed process with another process, before its /proc/pid/ files are analyzed but after apport has started, has been largely mitigated in apport (by thorough security checks in its consistencychecks() function).

To further detail this last point: perhaps surprisingly, a local attacker can send a SIGKILL signal to an already-crashed process, thus allowing the attacker to recycle the crashed process's pid (by creating many new processes until the crashed-and-killed process's pid is reused) and tricking apport into analyzing the /proc/pid/ files of the wrong process. This race condition has been exploited several times in the past; for example, the following outstanding write-ups by Philip Pettersson, Kevin Backhouse, Ryota Shiga, and Itai Greenhut:

- CVE-2015-1325: https://www.openwall.com/lists/oss-security/2015/05/21/10 - CVE-2019-15790: https://github.blog/security/vulnerability-research/ubuntu-apport-pid-recycling-security-vulnerability-cve-2019-15790/ - CVE-2020-15702: https://flatt.tech/research/posts/race-condition-vulnerability-in-handling-of-pid-by-apport/ - CVE-2021-25684: https://alephsecurity.com/2021/02/16/apport-lpe/

But as mentioned earlier, this race condition has now been largely mitigated in apport, by:

- immediately open()ing a file descriptor to the crashed process's /proc/pid/ directory and accessing all the files in this directory through this file descriptor and the at() syscalls (openat() etc);

- checking that the starttime in /proc/pid/stat is earlier than the starttime of apport itself (i.e., ensuring that an attacker has not replaced the crashed process with another process, after apport has started);

- double-checking that the real Uid and Gid in /proc/pid/status still match the real uid and gid of the crashed process at the time of its crash.

Last-minute note: we eventually verified that the starttime check is in fact useless, from a security point of view; an attacker can replace the crashed process with another process even before apport starts, and with the right timing can still give the kernel enough time to generate the core dump of the originally crashed process.

------------------------------------------------------------------------ Analysis ------------------------------------------------------------------------

Unfortunately, while reading apport's code we noticed that the function that handles crashes inside namespaces (checkglobalpidandforward(), at line 769) is called before the aforementioned security checks are run (in consistencychecks(), at line 951); in other words, an attacker can trick apport's checkglobalpidandforward() into analyzing the wrong process, while the kernel still sends the core dump of the originally crashed process to apport (over its file descriptor 0, stdin):

------------------------------------------------------------------------ 750 def main(args: list[str]) -> int: ... 769 if checkglobalpidandforward(options): 770 return 0 ... 775 return processcrashfromkernel(options) ------------------------------------------------------------------------ 921 def processcrashfromkernel(options: argparse.Namespace) -> int: ... 924 return processcrashfromkernelwithprocpid(options, procpid) ------------------------------------------------------------------------ 941 def processcrashfromkernelwithprocpid( 942 options: argparse.Namespace, procpid: ProcPid 943 ) -> int: ... 951 if not consistencychecks(options, processstart, procpid, realuser): 952 return 0 ------------------------------------------------------------------------

And so an attack idea against apport began to form in our mind:

a/ first, we fork() a new process and execve() a SUID or SGID program, and wait until it loads secret information into its memory (for example, password hashes from /etc/shadow);

b/ second, we crash this process at the right time, by kill()ing it with a core-dumping signal such as SIGSEGV or SIGSYS, thus causing the kernel to create a new apport process to analyze this crash;

c/ then, after apport has started but before it analyzes the crashed process's /proc/pid/ files, we SIGKILL the crashed process and quickly replace it with another process that is not SUID or SGID, but that is running inside a user, mount, and pid namespace (to pass the tests at lines 726-727, below);

(note: naturally, we use one of our bypasses in Ubuntu's unprivileged user namespace restrictions to create this namespace)

d/ as a result, apport connects to the Unix socket /run/apport.socket inside our mount namespace (at lines 521-584, below) and sends us its file descriptor 0, from where we can read the kernel-generated core dump of the originally crashed process, and hence the secret information from the memory of the SUID or SGID program (for example, password hashes).

------------------------------------------------------------------------ 712 def checkglobalpidandforward(options: argparse.Namespace) -> bool: ... 726 if not issamens(options.globalpid, "mnt"): 727 if not issamens(options.globalpid, "pid"): 728 forwardcrashtocontainer(options) 729 return True ------------------------------------------------------------------------ 509 def forwardcrashtocontainer( 510 options: argparse.Namespace, coredumpfd: int = 0, hascapsysadmin: bool = True 511 ) -> None: ... 521 prochostpidfd = os.open( 522 f"/proc/{options.globalpid}", os.ORDONLY | os.OPATH | os.ODIRECTORY 523 ) ... 531 sockfd = os.open( 532 "root/run/apport.socket", os.ORDONLY | os.OPATH, dirfd=prochostpidfd 533 ) ... 584 sock.connect(f"/proc/self/fd/{sockfd}") ------------------------------------------------------------------------

To put this theoretical attack idea into practice, we must solve three major problems:

1/ In step c/ we must SIGKILL the crashed process long before we can read any information from the file descriptor 0 that apport sends to us. This file descriptor 0 is the read end of a pipe whose internal 64KB buffer is filled by the kernel with the beginning of the crashed process's core dump, before we SIGKILL it.

The question, then, is: can we find a SUID or SGID program whose ELF segments and heap fit into the pipe's internal 64KB buffer, and whose heap contains secret information?

Luckily we found unixchkpwd, a small (~31KB) SUID-root or SGID-shadow program that is used by PAM to verify the password of a user, and which therefore loads the contents of /etc/shadow (password hashes) into its heap.

Last-minute note: while drafting this advisory, we realized that it might be possible to use /proc/pid/coredumpfilter to exclude the ELF segments from the program's core dump, which might make it possible to attack larger SUID programs such as su or sudo; this is left as an exercise for the interested reader.

2/ In step b/ we must win a first race condition: we must crash the SUID process "at the right time", with a SIGSEGV or SIGSYS for example. If we crash it too early, then the password hashes from /etc/shadow are not loaded into the heap yet; if we crash it too late, then the password hashes in the heap are already overwritten with other information.

Ideally, to reliably win this race condition, we should add an INCLOSENOWRITE watch on /etc/shadow, which would allow us to crash the SUID process as soon as the contents of /etc/shadow are loaded into its heap. Unfortunately, we cannot add such a watch, because /etc/shadow is not readable by us. As a makeshift solution, we add an INCLOSENOWRITE watch on /etc/passwd instead, which is opened and closed immediately before /etc/shadow.

With our proof of concept, we almost always obtain some password hashes from unixchkpwd's heap, and from time to time we also obtain the entire contents of /etc/shadow. In any case, we can simply re-execute our proof of concept until we obtain the password hash that we are looking for, and we believe that the reliability of this step b/ can still be improved.

3/ In step c/ we must win a second race condition: we must SIGKILL the crashed SUID process and "quickly" replace it with a non-SUID namespaced process (before apport calls its checkglobalpidandforward()). If we SIGKILL it too early, then the kernel does not have enough time to write the beginning of the crashed process's core dump into apport's file descriptor 0; if we SIGKILL it too late, then apport analyzes the crashed process's /proc/pid/ (instead of our namespaced process's /proc/pid/) and therefore does not send us its file descriptor 0.

In our experiments, and depending on the test machines, it takes between 1 and 4 minutes to replace the crashed SUID process with another process (i.e., to recycle its pid) because /proc/sys/kernel/pidmax is 4M (2^22) nowadays, not 32K (note: we call clone() with most of the CLONE flags to create new processes, to minimize the work done by the kernel; it would take 3 to 6 times longer if we were simply calling fork()).

Consequently, we cannot just "quickly" replace the crashed SUID process in step c/; instead:

- in step b/ we do not immediately crash the SUID process (with SIGSEGV or SIGSYS), but we first SIGSTOP it, then create ~4M processes until their pids wrap around and almost reach the pid of the SUID process, and finally we crash (SIGSEGV or SIGSYS) and resume (SIGCONT) the SUID process;

- in step c/ we SIGKILL the crashed SUID process, and quickly create a mere handful of namespaced processes until their pids reach and reuse the pid of the crashed-and-killed SUID process.

Our proof of concept always wins this second race condition (the "kill-and-replace" race condition): because apport is written in Python, it loads numerous .pyc files during its initialization, so we simply add an INOPEN watch on one of these files (on aptdpkg.cpython-312.pyc for example) and still have plenty of time (after apport has triggered our watch point) to SIGKILL and replace the crashed SUID process with a namespaced process (before apport analyzes its /proc/pid/ files).

------------------------------------------------------------------------ Proof of concept ------------------------------------------------------------------------

$ grep PRETTYNAME= /etc/os-release PRETTYNAME="Ubuntu 24.04.2 LTS"

$ id uid=1001(evey) gid=1001(evey) groups=1001(evey),100(users)

$ while true; do core="$(printf 'whatever\0' | ./CVE-2025-5054 /usr/sbin/unixchkpwd "$USER" nullok)"; if tr -c ' -~' '\n' < "$core" | grep '\$[0-9A-Za-z]\+\$[0-9A-Za-z./]'; then break; fi; done

... pid 1093 tid 1030 core will be dumped in /tmp/run.q5qBcg signal 9 accept 4 args 1093 31 18446744073709551615 2 fd 5 died in childuserns: 151 status 1 died in main: 280 $y$j9T$KC0.pKjUYzrr3L8VVNQ8l/$11KufHkbNKHRxgolryPxDQDZ.Ox9kG4RIv0Pxe1FgxA $y$j9T$KC0.pKjUYzrr3L8VVNQ8l/$11KufHkbNKHRxgolryPxDQDZ.Ox9kG4RIv0Pxe1FgxA theadmin:$6$7Ag0AvjQl4XQvSO4$T1mMcQeC0K7FICHEj9pNV20XcUX4IW6Xqg45lyuORtia1vPCOy2ZrFlTa.ZEf0EAO6rpNRma1ucCjO3aL64KW0:20145:0:99999:7::: evey:$y$j9T$KC0.pKjUYzrr3L8VVNQ8l/$11KufHkbNKHRxgolryPxDQDZ.Ox9kG4RIv0Pxe1FgxA:20145:0:99999:7:::

======================================================================== Local information disclosure in systemd-coredump (CVE-2025-4598) ========================================================================

------------------------------------------------------------------------ Background ------------------------------------------------------------------------

While working on Ubuntu's apport, we remembered that various other distributions (Red Hat Enterprise Linux 9 and Fedora for example) use systemd-coredump as a core-dump handler in /proc/sys/kernel/corepattern (instead of apport). We began to wonder: how does systemd-coredump solve the kill-and-replace race condition that we exploited against apport?

Similarly to apport, systemd-coredump writes all core files into a hard-coded directory, /var/lib/systemd/coredump/. Before December 2022, systemd-coredump allowed users to read all of their core files (through file ACLs), including the core files of SUID or SGID programs, which of course allowed local attackers to read the contents of /etc/shadow by simply crashing su for example; this vulnerability was CVE-2022-4415, discovered and published by Matthias Gerstner:

https://www.openwall.com/lists/oss-security/2022/12/21/3

This old vulnerability was patched by introducing a new function, grantuseraccess(), which decides whether a user should be allowed to read a core file or not, by analyzing the /proc/pid/auxv of the crashed process: if its ATUID and ATEUID match, and if its ATGID and ATEGID match, and if its ATSECURE flag is 0, then read access is allowed; otherwise (if the crashed process is SUID or SGID), read access is denied (only root can read the core file).

------------------------------------------------------------------------ Analysis ------------------------------------------------------------------------

Unfortunately, we soon realized that systemd-coredump does not provide any protection at all against the kill-and-replace race condition that we exploited in apport. In other words, an attacker can simply crash a SUID process such as unixchkpwd, SIGKILL and replace it with a non-SUID process (before its /proc/pid/auxv is analyzed by systemd-coredump), and therefore gain read access to the core file of the crashed SUID process, and hence to the contents of /etc/shadow.

On the one hand, exploiting systemd-coredump is easier than exploiting apport, because we do not need to replace the crashed SUID process with a namespaced process: we can replace it with any non-SUID process, whose ATUID and ATEUID match, whose ATGID and ATEGID match, and whose ATSECURE flag is 0.

On the other hand, winning the kill-and-replace race condition against systemd-coredump is harder: unlike apport, systemd-coredump is written in C, and its initialization takes little time. To widen the window of the race condition, we pass an argv[0] of 128K '\177' characters to the SUID process: this slows down the analysis of its /proc/pid/cmdline (by systemd-coredump, before the analysis of its /proc/pid/auxv) and gives us enough time to replace the crashed SUID process with a non-SUID process.

------------------------------------------------------------------------ Proof of concept ------------------------------------------------------------------------

$ grep PRETTYNAME= /etc/os-release PRETTYNAME="Fedora Linux 41 (Server Edition)"

$ id uid=1001(evey) gid=1001(evey) groups=1001(evey) context=unconfinedu:unconfinedr:unconfinedt:s0-s0:c0.c1023

$ while true; do pid="$(printf 'whatever\0' | ./CVE-2025-4598 /usr/sbin/unixchkpwd "$USER" nullok)"; pidwait -f /usr/lib/systemd/systemd-coredump; if coredumpctl -1 dump "$pid" 2>/dev/null | strings -a | grep '\$[0-9A-Za-z]\+\$[0-9A-Za-z./]'; then break; fi; done

... pid 364536 tid 364521 tid 364540 died in main: 177 theadmin:$y$j9T$APKdqQO.brzhEbC2JFd.5zb7$Rz2q.0umBr8AmkwlozWr8/yphm/ckEHIOMo9vcj.Wj/::0:99999:7::: evey:$y$j9T$QUW3HEErO9CYuGrRhiQjt.$.befySFW/nA48280u/Hk1XrcA2yDZ6Z1s7iRf91nJuA:20188:0:99999:7:::

======================================================================== Acknowledgments ========================================================================

We thank Ubuntu's security team and apport's developers (Octavio Galland and Benjamin Drung in particular), and systemd's developers (Zbigniew Jedrzejewski Szmek and Luca Boccassi in particular), for their hard work on this release. We also thank Red Hat Product Security (Marco Benatto in particular), and the linux-distros@openwall (Solar Designer, Seth Arnold, Salvatore Bonaccorso, David Fernandez Gonzalez, in particular), for their help with this release. Finally, we thank Christian Brauner for the %F/pidfd kernel feature.

======================================================================== Timeline ========================================================================

2025-03-21: We sent a draft of our advisory and a first proof of concept (against unixchkpwd) to Ubuntu's security team.

2025-04-10: We sent a draft of our advisory and a first proof of concept (against unixchkpwd) to systemd's developers.

2025-04-17: We sent a second proof of concept (against sshd) to systemd's developers.

2025-04-22: We sent a second proof of concept (which defeats apport's starttime check) to Ubuntu's security team and apport's developers.

2025-05-23: We sent a draft of our advisory to the linux-distros@openwall.

2025-05-29: Coordinated Release Date (16:00 UTC).

dnsmasq, as shipped with Fedora and Red Hat Enterprise Linux, has a default configuration that makes it listen on any interface and accept queries from addresses outside of its local subnet. In particular, the option local-service is not enabled. Users that enable dnsmasq on their system with its default configuration may inadvertently make it an open resolver accessible from any address on the internet, potentially being involved in Distributed Denial of Service (DDoS) attacks against a victim.

c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG. This issue was patched in version 1.19.1.

Bottles before 51.0 mishandles YAML load, which allows remote code execution via a crafted file.

Currently, the fields in the query string are not sanitized for special characters in Fedora Koji

Stack-based buffer overflow in the readarticle function in getarticle.c in newsx 1.6 allows remote attackers to execute arbitrary code via a news article containing a large number of lines starting with a period.

Multiple memory leaks in Red Hat Directory Server 7.1 before SP7, Red Hat Directory Server 8, and Fedora Directory Server 1.1.1 and earlier allow remote attackers to cause a denial of service (memory consumption) via vectors involving (1) the authentication / bind phase and (2) anonymous LDAP search requests.

It was discovered that Red Hat Directory Server and Fedora Directory Server is prone to a temporary denial of service attack (high CPU usage) via crafted LDAP search patterns. LDAP search patterns are internally translated to regular expressions. If the regular expression is matched against specially crafted record already stored in the LDAP, it may cause regular expression NFA to iterate over large amount of states, causing one slapd thread to occupy CPU for excessive amount of time.

Additionally, due to a current design of the regular expression handling code, only one slapd thread can execute regular expression NFA code at the time. Because of that, during the processing of such CPU intensive search request, all other search requests using patterns are blocked.

Affected version: Red Hat Directory Server 7.1 and 8 Fedora Directory Server 1.1.1

It was discovered that multiple CGI scripts used by Red Hat / Fedora Directory Server did not properly sanitize %-escaped inputs, resulting in a possibility to conduct cross-site scripting (XSS) attacks.

Issue was caused by a flow in an adminutil library that contain common functionality used by multiple CGI scripts, such as affected GET / POST argument parsing.

Issue is know to affect some Administration Express scripts and Directory Server Gateway (DSGW) scripts.

Affected version: Red Hat Directory Server 7.1 Red Hat Directory Server 8 (flaw limited to Administration Express issues, as DSGW component is not shipped) Fedora Directory Server

A TOCTOU race condition was found in the way 'annotate-output' (used to execute a program annotating the output linewise with time and stream) tool of rpmdevtools, a suite of scripts and (X)Emacs support files to aid in development of RPM packages, performed management of its temporary files used for standard output and standard error output. A local attacker could use this flaw to conduct symbolic link attacks, possibly leading to their ability in an unauthorized way to alter files belonging to the user running the 'annotate-output' tool.

Issue found by Jim Meyering of Red Hat.

Hi Neil, On 6. Aug 2024, at 11:02, Neil Horman <nhorman () openssl org> wrote:

1) Are distributions/users comfortable with this approach in the time frame proposed? I don’t think this will be a problem for Fedora, CentOS Stream, and RHEL. They mostly disable TLS <1.2 without a simple way to bring it back already. 2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds? I would strongly argue for keeping those disabled in Fedora. It’s already not simple to re-enabled them in CentOS Stream or RHEL. 3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol? I believe the best you can do as a library is what you are already doing: Disabling by default, and possibly marking any TLS-1.0/1.1-specific APIs deprecated.

Logging to stderr from a library is out of the question. Logging to syslog can fail due to SELinux on distros that have it.

The only other good solution we’ve come up with is to add a USDT probe point to deprecated code paths and provide a utility for users to run on their system that will highlight any use of these code paths. That’s Linux-specific, and most users won’t run such a tool, though.

HTH, Clemens

-- Clemens Lang RHEL Crypto Team Red Hat

The pcs daemon (pcsd) in PCS 0.9.137 and earlier does not include the HTTPOnly flag in a Set-Cookie header, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie. NOTE: this issue was SPLIT from CVE-2015-1848 per ADT2 due to different vulnerability types.

The pcs daemon (pcsd) in PCS 0.9.137 and earlier does not set the secure flag for a cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http session. NOTE: this issue was SPLIT per ADT2 due to different vulnerability types. CVE-2015-3983 is for the issue with not setting the HTTPOnly flag.

Hi Alexander,

On Tue, Jul 23, 2024 at 09:23:10PM +0200, Solar Designer wrote: Hi,

I've finally reviewed the links and re-read the thread. Looks like we're OK to proceed with adding CentOS Project's Hyperscale SIG as a linux-distros member.

Michel, please e-mail me off-list with PGP keys for all of you who need to be subscribed for Hyperscale. I also need to know who will be managing this subscription on your end (informing me of any changes in who's to stay subscribed). Thank you! I'll email once I have collected all the keys. On Wed, Jul 10, 2024 at 06:54:13PM -0500, Michel Lind wrote: All three of us are Fedora developers - but AIUI, we will not and can not use membership here to contribute Fedora patches - until the embargo is over.

For Hyperscale itself we plan to use the head start to have local builds ready to go, and commit and do a public build as soon as the embargo is over; if it needs collaboration we can use private Git repos and E2EE private chats to discuss the fix among ourselves.

This is, to the best of my knowledge, similar to how AlmaLinux handles embargoed security issues - the fix is ready to go but is only made available once the embargo is lifted.

Now - wearing our Fedora hats, we certainly would try and help get this fixed in Fedora once the embargo is over (as we've done before) - and knowing a CVE is going to be made public would certainly help (e.g. trying to make sure one of us is around) - but we won't be participating in the list wearing our Fedora hat, or discuss embargoed issues with people not on the list. This understanding is correct. The membership and embargoed info is only for the specific distro "except with the reporter's explicit approval". This exception means that you may occasionally ask whoever reported the issue to linux-distros for permission to use the information e.g. also for preparing a fix for Fedora even though you're subscribed for Hyperscale. To avoid miscoordination, please keep such requests also CC'ed to the list. Uses of this exception have been very rare so far, and it is expected that you wouldn't use it often, or else it'd make more sense to discuss the additional distro becoming a member. Thanks. Good to know this exception exists, but I'm hoping to prod Fedora to onboard itself as a member anyway. FWIW, Fedora's fix for CVE-2024-6387 was quite timely as-is:

commit dcbca7b947cf82c30d6f477a26efd2f765204fe6 Author: Gordon Messmer <gordon.messmer () gmail com> AuthorDate: Mon Jul 1 20:49:16 2024 -0700 Commit: Gordon Messmer <gordon.messmer () gmail com> CommitDate: Tue Jul 2 00:48:16 2024 -0700

Patch 9.6p1 for CVE-2024-6387

Mon Jul 01 2024 Gordon Messmer <gordon.messmer () gmail com> - 9.6p1-12 - Patch 9.6p1 for CVE-2024-6387

On one hand, this confirms that Fedora cares. On the other, for an issue with a trivial patch, I don't know if Fedora could have done much or anything more to prepare. It was timely .. but there was some scramble in Fedora's security room the morning the embargo was lifted. It turns out the development Rawhide branch was not in a buildable state at that moment - not a big deal, I pointed out at the time that it's more important to fix the stable releases - but with access to the embargo, someone could have fixed the Rawhide build in preparation I suppose. OpenSSH 9.8 released on July 1 also fixed "Logic error in ssh(1) ObscureKeystrokeTiming", which became CVE-2024-39894 by July 3:

https://www.openwall.com/lists/oss-security/2024/07/03/6

Per upstream, this issue affects "9.5 through 9.7 (inclusive)", so I guess Fedora's package based on 9.6p1 is vulnerable. There doesn't appear to be a fix in the package yet. I see this is being tracked in:

https://bugzilla.redhat.com/showbug.cgi?id=2295615

which is assigned to Dmitry Belyavskiy, who is also the maintainer of the OpenSSH package in RHEL and CentOS Stream. RHEL is not affected and the issue is low severity, so will probably take a long while to fix in Fedora via Red Hat. Maybe something the community could do quicker? This is not directly related to possible linux-distros membership; this issue wasn't even on linux-distros. Yeah - the CVE fixes were done by a non-maintainer anyway (Dmitry understandably has his hands full with fixing RHEL and CentOS Stream). This is tangential - but having a well-coordinated security team in Fedora, that participates in this list and in linux-distros, would likely help - e.g. by ensuring that the ACL of key packages like openssh correlates to who often contributes to it, and by making sure issues like these get addressed sooner rather than later.

-- o) Michel Lind ( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

Hi,

I've finally reviewed the links and re-read the thread. Looks like we're OK to proceed with adding CentOS Project's Hyperscale SIG as a linux-distros member.

Michel, please e-mail me off-list with PGP keys for all of you who need to be subscribed for Hyperscale. I also need to know who will be managing this subscription on your end (informing me of any changes in who's to stay subscribed).

On Wed, Jul 10, 2024 at 06:54:13PM -0500, Michel Lind wrote: All three of us are Fedora developers - but AIUI, we will not and can not use membership here to contribute Fedora patches - until the embargo is over.

For Hyperscale itself we plan to use the head start to have local builds ready to go, and commit and do a public build as soon as the embargo is over; if it needs collaboration we can use private Git repos and E2EE private chats to discuss the fix among ourselves.

This is, to the best of my knowledge, similar to how AlmaLinux handles embargoed security issues - the fix is ready to go but is only made available once the embargo is lifted.

Now - wearing our Fedora hats, we certainly would try and help get this fixed in Fedora once the embargo is over (as we've done before) - and knowing a CVE is going to be made public would certainly help (e.g. trying to make sure one of us is around) - but we won't be participating in the list wearing our Fedora hat, or discuss embargoed issues with people not on the list. This understanding is correct. The membership and embargoed info is only for the specific distro "except with the reporter's explicit approval". This exception means that you may occasionally ask whoever reported the issue to linux-distros for permission to use the information e.g. also for preparing a fix for Fedora even though you're subscribed for Hyperscale. To avoid miscoordination, please keep such requests also CC'ed to the list. Uses of this exception have been very rare so far, and it is expected that you wouldn't use it often, or else it'd make more sense to discuss the additional distro becoming a member. I am curious what this could mean for Fedora Asahi Remix [0], as the applicants maintain both distros.

Is there interest in the Asahi SIG applying as well?

I heartily endorse the applicants membership request and appreciate their work. Hooray for ARM \o/ So... if this works for Hyperscale, we could potentially discuss with other Fedora developers about having Fedora itself be represented in linux-distros. Something to bring up at Flock! There's already some discussion of this in the Fedora Security Matrix room w.r.t. last week's OpenSSH CVE. FWIW, Fedora's fix for CVE-2024-6387 was quite timely as-is:

commit dcbca7b947cf82c30d6f477a26efd2f765204fe6 Author: Gordon Messmer <gordon.messmer () gmail com> AuthorDate: Mon Jul 1 20:49:16 2024 -0700 Commit: Gordon Messmer <gordon.messmer () gmail com> CommitDate: Tue Jul 2 00:48:16 2024 -0700

Patch 9.6p1 for CVE-2024-6387

Mon Jul 01 2024 Gordon Messmer <gordon.messmer () gmail com> - 9.6p1-12 - Patch 9.6p1 for CVE-2024-6387

On one hand, this confirms that Fedora cares. On the other, for an issue with a trivial patch, I don't know if Fedora could have done much or anything more to prepare.

OpenSSH 9.8 released on July 1 also fixed "Logic error in ssh(1) ObscureKeystrokeTiming", which became CVE-2024-39894 by July 3:

https://www.openwall.com/lists/oss-security/2024/07/03/6

Per upstream, this issue affects "9.5 through 9.7 (inclusive)", so I guess Fedora's package based on 9.6p1 is vulnerable. There doesn't appear to be a fix in the package yet. I see this is being tracked in:

https://bugzilla.redhat.com/showbug.cgi?id=2295615

which is assigned to Dmitry Belyavskiy, who is also the maintainer of the OpenSSH package in RHEL and CentOS Stream. RHEL is not affected and the issue is low severity, so will probably take a long while to fix in Fedora via Red Hat. Maybe something the community could do quicker? This is not directly related to possible linux-distros membership; this issue wasn't even on linux-distros.

Alexander

Hi,

Summary:

This message is about issues in grub-set-bootflag.c commonly installed as grub2-set-bootflag, which is Red Hat's addition (not part of upstream GRUB project) used at least in Fedora and RHEL and its downstreams. It is a SUID root program. I think its latest development source code is currently located in this branch:

https://github.com/rhboot/grub2/tree/fedora-40

On non-OSTree distros, this program's purpose appears to be purely cosmetic - hide the boot menu if the system had already successfully booted up with its current kernel and a user had successfully logged in.

Impact of the issues I identified (through my work at CIQ on Rocky Linux) is rather limited - denial of service and resource limit bypass.

I pre-notified Red Hat grub2 package maintainers about upcoming issues in this program in late December, and reported them in detail via Red Hat Bugzilla on January 3:

https://bugzilla.redhat.com/showbug.cgi?id=2256678

(This is currently a private "bug", hopefully it will be opened soon.)

I also reported this to linux-distros on January 24, and today February 6 is the coordinated public disclosure.

Attached are my currently proposed patches (two revisions, see below), tested by me on Rocky Linux 9.3, and (for the later revision) also by people at Red Hat.

Red Hat assigned this issue CVE-2024-1048 and rated it as CVSSv3.1 Base Score 3.3 and Moderate severity, which I agree with:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L - 3.3

Technically, the RLIMITNPROC bypass could mean S:C A:H, resulting in a score of 6.5, however in practice for this to matter the resource limits would need to be set up, which by default and on most systems they are not anyway. That is, by default almost the same kind and extent of DoS is possible by a simple "fork bomb" from the user's account, so there's no additional vulnerability.

I'd like to thank Red Hat, and especially Marta Lewandowska for her help in coordinating this disclosure and testing the patches.

Overall, I think that at least on Enterprise Linux distros unprivileged setting of boot flags should be disabled by default. It is of questionable value and isn't worth the risk. That said, I understand that for now it may be easier for distros to patch than to re-think it.

Detail:

In 2019, Tavis Ormandy reported that the original implementation of grub2-set-bootflag could be abused to truncate the grubenv file. This is CVE-2019-14865 and was fixed back then:

https://bugzilla.redhat.com/showbug.cgi?id=CVE-2019-14865 https://access.redhat.com/errata/RHSA-2020:0335

Taking a fresh look at grub2-set-bootflag, I saw some other ways in which users could still abuse this little program:

1. After CVE-2019-14865 fix, grub2-set-bootflag no longer rewrites the grubenv file in-place, but writes into a temporary file and renames it over the original, checking for error returns from each call first. This prevents the original file truncation vulnerability, but it can leave the temporary file around if the program is killed before it can rename or remove the file. There are still many ways to get the program killed, such as through RLIMITFSIZE triggering SIGXFSZ (tested, reliable) or by careful timing (tricky) of signals sent by process group leader, pty, pre-scheduled timers, SIGXCPU (probably not an exhaustive list). Invoking the program multiple times fills up /boot (or if /boot is not separate, then it can fill up the root filesystem). Since the files are tiny, the filesystem is likely to run out of free inodes before it'd run out of blocks, but the effect is similar - can't create new files after this point (but still can add data to existing files, such as logs).

2. After CVE-2019-14865 fix, grub2-set-bootflag naively tries to protect itself from signals by becoming full root. (This does protect it from signals sent by the user directly to the PID, but e.g. "kill -9 -1" by the user still works.) A side effect of such "protection" is that it's possible to invoke more concurrent instances of grub2-set-bootflag than the user's RLIMITNPROC would normally permit (as specified e.g. in /etc/security/limits.conf, or say in Apache httpd's RLimitNPROC if grub2-set-bootflag would be abused by a website script), thereby exhausting system resources (e.g., bypassing RAM usage limit if RLIMITAS was also set).

3. umask is inherited. Again, due to how the CVE-2019-14865 fix creates a new file, and due to how mkstemp() works, this affects grubenv's new file permissions. Luckily, mkstemp() forces them to be no more relaxed than 0600, but the user ends up being able to set them e.g. to 0. Luckily, at least in my testing GRUB still works fine even when the file has such (lack of) permissions.

The attached -1 patch deals with my example abuses above as follows:

1. RLIMITFSIZE is pre-checked, so this specific way to get the process killed should no longer work. However, this isn't a complete fix because there are other ways to get the process killed after it has created the temporary file.

The patch also fixes bug 1975892 ("RFE: grub2-set-bootflag should not write the grubenv when the flag being written is already set") and similar for "menushowonce", which further reduces the abuse potential.

2. RLIMITNPROC bypass should be avoided by not becoming full root (aka dropping the partial "kill protection").

3. A safe umask is set.

The -1 patch is a partial fix (temporary files can still accumulate, but this is harder to trigger). It should be safe to use.

The attached -7 patch additionally switches to usage of per-user fixed temporary filenames along with a weird locking mechanism, which is explained in source code comments. This is a more complete fix (temporary files can't accumulate). Unfortunately, it introduces new risks (by working on a temporary file shared between the user's invocations), which are hopefully avoided by the patch's elaborate logic. I actually got it wrong at first, which suggests that this logic is hard to reason about, and more errors or omissions are possible. It also relies on the kernel's primitives' exact semantics to a greater extent (nothing out of the ordinary, though).

Both patches also fix potential 1- or 2-byte over-read of env[] if its content is malformed - this was not a security issue since the grubenv file is trusted input, and the fix is just for robustness.

Also attached is a program I wrote and used to test the unusual approach to locking implemented in the -7 patch here.

Remaining issues that I think cannot reasonably be fixed without a redesign (e.g., having per-flag files with nothing else in them) and without introducing new issues:

A. A user can still revert a concurrent user's attempt of setting the other flag - or of making other changes to grubenv by means other than this program.

B. One leftover temporary file per user is still possible.

Needs comments by people more familiar with GRUB and its configurations in use:

C. One hopefully non-issue (but I am not sure): can "menushowonce" possibly make the system stuck at next boot? Apparently, not with defaults, but maybe along with other GRUB settings in place? If so, it could be unsafe to expose setting this flag to users. A misfeature?

Security hardening not yet implemented (would require changes or at least decisions outside of this program's code):

D. If this program's functionality is really desirable anywhere at all, perhaps its availability should vary by distro - e.g., have it on (some builds of) Fedora, but not on Enterprise Linux distros - and then don't make this program SUID root where that is not needed.

E. The program could refuse to work (exit early) if invoked by an unexpected system pseudo-user. Apparently, it's expected to be invoked by all normal users, but we can nevertheless disallow uid < 1000, so the program couldn't be abused by a compromised system pseudo-user account in a multi-vulnerability multi-step attack.

F. grubenv could be made a symlink into a subdirectory writable by a group, then SGID to that group could be used, mostly to reduce impact of some other (yet unidentified) vulnerabilities/attacks on the program.

Regarding remaining issue/idea D above, even RHEL installs /usr/lib/systemd/user/grub-boot-success.service, which then fails to run upon user login when the program is not user-accessible. The impact from this failure, however, appears to be very limited - just some noise in the logs. The -7 patch includes a piece to reduce such noise if the program is installed e.g. mode 755.

Overall, my understanding is that the program (and other related parts using the boot success flag) is most useful on systems with OSTree, which means some builds of Fedora, right? Per Wikipedia it's "Fedora's atomic spins (Silverblue, Kinoite, and Sericea)". https://en.wikipedia.org/wiki/OSTree

Should we get rid of it on other distros? Or on the contrary, should we make real, non-cosmetic use of the boot flag? If not setting the flag would trigger automatic fallback to the previous kernel, that could be a valuable enough feature to justify some risks, but on the other hand such fallback would also be unexpected by many and it'd be a security concern on its own. A server could successfully boot into the new kernel and be in use without any Unix user logins to it occurring until next reboot. It shouldn't then revert to the old kernel just because no one had logged in. So the feature would need to be opt-in by the sysadmin or/and the criteria for fallback would need to be different.

Alexander