Re: [oss-security] CVE-2025-52555 Ceph: CephFS Permission Escalation Vulnerability in Ceph Fuse mounted FS

On 6/26/25 15:09, Sage [They / Them] McTaggart wrote: Hello all, A flaw was found in CephFS. An unprivileged user can escalate to root privileges in a ceph-fuse mounted CephFS by chmod 777 a directory owned by root to gain access. [...] It is patched via 17.2.8

Re: [oss-security] Re: Linux kernel: HFS+ filesystem implementation issues, exposure in distros

On 6/5/25 21:24, Solar Designer wrote: On Tue, Jun 03, 2025 at 12:38:11PM +0200, Attila Szasz wrote: [...] Since then I checked, and 5.4 LTS (any<=5.6) had been vulnerable without the need to ever mount an untrusted/malformed FS just by systematically corrupting a vanilla fs's B-trees with norma

Re: [oss-security] describing affected systems (was: screen: Multiple Security Issues in Screen (mostly affecting release 5.0.0 and setuid-root installations))

On 5/16/25 13:07, Eli Schwartz wrote: On 5/16/25 12:31 PM, Taylor R Campbell wrote: [...] (a) the same pkgsrc packages are available on, e.g., NetBSD 9.x (which is not EOL); and (b) pkgsrc is used on platforms other than NetBSD, including macOS, SmartOS, and various Linux distribution

Re: [oss-security] CVE-2025-3512: Qt Base QTextMarkdownImporter Front Matter Buffer Overflow

On 4/24/25 19:08, Solar Designer wrote: On Thu, Apr 24, 2025 at 09:06:26PM +0200, Jakub Wilk wrote: * Solar Designer , 2025-04-24 20:32: There appears to be a growing trend towards calling OOB reads "buffer overflows". Part of the problem may be that AddressSanitizer uses this unforuntate term

Re: [oss-security] CVE-2025-29868: Apache Answer: Using externally referenced images can leak user privacy.

On 3/31/25 21:44, Enxin Xie wrote: [...] Description: Private Data Structure Returned From A Public Method vulnerability in Apache Answer. This issue affects Apache Answer: through 1.4.2. If a user uses an externally referenced image, when a user accesses this image, the provider of the ima

Re: [oss-security] tj-action/changed-files GitHub action was compromised

On 3/15/25 14:03, Mark Esler wrote: On March 14 2025 at 16:57:45 UTC the tj-action/changed-files GitHub action was compromised with commit 0e58ed8 ("chore(deps): lock file maintenance (#2460)"). This commit was added to all 361 tagged versions of the GitHub action. This malicious commit results i

Re: [oss-security] CVE-2025-1937+more: Numerous memory-safety issues in Firefox & Thunderbird

On 3/10/25 08:30, Valtteri Vuorikoski wrote: [...] However the only issue ranked critical only affects Android, looks like desktop versions top out at high. My understanding is that the issue was *reported* by the Android project, but it affects *ALL* builds, including desktop. -- Jacob

Re: [oss-security] AMD Microcode Signature Verification Vulnerability

On 3/5/25 23:34, Solar Designer wrote: On Wed, Mar 05, 2025 at 11:03:49PM -0600, Jacob Bachmeyer wrote: [...] Forging On We noticed that the key from an old Zen 1 CPU was the example key of the NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until

Re: [oss-security] AMD Microcode Signature Verification Vulnerability

On 3/5/25 21:30, Solar Designer wrote: [...] I'll focus on what the vulnerability and its fix are: [...] Forging On We noticed that the key from an old Zen 1 CPU was the example key of the NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until at le

[oss-security] Re: pam_pkcs11: Possible Authentication Bypass in Error Situations (CVE-2025-24531)

On 2/6/25 08:55, Matthias Gerstner wrote: [...] On the use of `PAM_SUCCESS` --- PAM modules that only serve utility functions but do not actually authenticate could consider not returning `PAM_SUCCESS` but `PAM_IGNORE` instead. This would avoid unintended successful auth

Re: [oss-security] AMD Microcode Signature Verification Vulnerability

On 2/6/25 17:04, trinity pointard wrote: If an attacker is able to control the hypervisor (necessary to load rogue microcode) and the processor microcode, how can the VM trust that it is actually verifying that attestation and not being sent down a "oh yes it is exactly what you want it to be" ga

Re: [oss-security] AMD Microcode Signature Verification Vulnerability

On 2/4/25 04:10, Solar Designer wrote: On Wed, Jan 22, 2025 at 07:52:48AM -0800, Tavis Ormandy wrote: [...] AMD SEV-SNP users can verify the fix by confirming TCB values for SNP in their attestation reports (can be observed from a VM, consult AMD's security bulletin for further details). [...]

[oss-security] Re: pam-u2f: problematic PAM_IGNORE return values in pam_sm_authenticate() (CVE-2025-23013)

On 1/15/25 06:03, Matthias Gerstner wrote: There exist utility modules that don't actually authenticate but perform helper functions or enforce policy. An example is the pam_faillock [8] module, which can be added to the `auth` management group to record failed authentication attempts and lock th

Re: [oss-security] CVE-2024-36905: Linux kernel: Divide-by-zero on shutdown of TCP_SYN_RECV sockets

On 10/29/24 08:03, Joel GUITTET wrote: We would like to ask your advice about the CVE-2024-36905 (tcp shutdown vulnerability). NIST indicates a network vector while AWS and Red Hat indicates local attack vector. Our cybersecurity team has difficulties to justify that a local vector is appropri

Re: [oss-security] feedback requested regarding deprecation of TLS 1.0/1.1

Steffen Nurpmeso wrote: Jacob Bachmeyer wrote in <66c2acb0.2040...@gmail.com>: [...] |Removing support for TLS1.0/1.1 has definite costs in compatibility, |costs that hit particularly hard with legacy embedded devices for which |no updates will be available. Given that TLS1.2

Re: [oss-security] feedback requested regarding deprecation of TLS 1.0/1.1

Peter Gutmann wrote: Jacob Bachmeyer writes: The AtE mode has problems, but is still supported in TLS1.2. (Why was EtA not also introduced in TLS1.2?) It was: https://datatracker.ietf.org/doc/html/rfc7366 So you don't need any new modes, just an extension to signal its pre

Re: [oss-security] feedback requested regarding deprecation of TLS 1.0/1.1

Jeffrey Walton wrote: On Fri, Aug 16, 2024 at 10:01 AM Jacob Bachmeyer wrote: Hanno Böck wrote: Hello, I have no particular insight on the prevalence of TLS 1.0/1.1 these days, but I want to make a more general comment. My impression of OpenSSL is that it has a strong tendency to

Re: [oss-security] feedback requested regarding deprecation of TLS 1.0/1.1

Hanno Böck wrote: Hello, I have no particular insight on the prevalence of TLS 1.0/1.1 these days, but I want to make a more general comment. My impression of OpenSSL is that it has a strong tendency to ship "bloat", i.e., features that either barely anyone needs, but that still get added (remem

Re: [oss-security] collision confounders (was: feedback requested regarding deprecation of TLS 1.0/1.1)

Peter Gutmann wrote: steffen writes: That is: whether "vulnerability" thus means to create a fake packet with identical MD-5 and SHA-1 hashes (it seems TLSv1.1 always uses both concurrently, at least for RSA) as the cryptographically verifiable one that ships with the packet. It seems to m

Re: [oss-security] feedback requested regarding deprecation of TLS 1.0/1.1

Pat Gunn wrote: OpenSSL is an important and security-critical piece of software; it's important that it be maintainable, analysable for security properties, and that at runtime people don't have to worry about weird old code paths leading to breaches or instability. By all means minimize the

Re: [oss-security] feedback requested regarding deprecation of TLS 1.0/1.1

Clemens Lang wrote: On 7. Aug 2024, at 19:48, Solar Designer wrote: 1. Hosting a public server that's meant to be usable by the widest audience possible, including from both up-to-date and older systems. For example, a website should display in latest web browsers, but command-line downloads fr

Re: [oss-security] ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch

Steffen Nurpmeso wrote: [...] Some findings: . I note that the mentioned files are writable by only root (and i would assume MAP_DENYWRITE to only work if i could do so myself). I believe that most executables are writable only by root, but available to unprivileged users. Since the

Re: [oss-security] ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch

Steffen Nurpmeso wrote: [...] So if someone says "this was a source of denial‐of‐service attacks" then i need to wrap my head, and it is not as if an in-between-the-lines reference to MAP_DENYWRITE ring any bells except that i think the flag has been removed. The manpage indicates that, long

Re: [oss-security] backtrace_symbols() misuse by Ceph and its supposedly-safe use

Alexander Patrakov wrote: [...] What would be a good solution (as in: something that does not convert crashes into deadlocks) here? I understand that, after memory corruption, we are already in the UB territory, but is there anything better possible than what is implemented? I would suggest a m

Re: [oss-security] CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems

Jeffrey Walton wrote: On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer wrote: Qualys Security Advisory wrote: [...] A thought occurred to me late last night: this exploit required the use of a very long fake user name (~128KB). No legitimate account will have such a name

Re: [oss-security] CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems

Qualys Security Advisory wrote: Qualys Security Advisory regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387) [...] SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006) =

Re: [oss-security] Microsoft Device Firmware Configuration Interface (DFCI) in Linux efivars directory

Solar Designer wrote: Hi, Corey's message is confused and there's no indication in it whether the system was compromised, so that part doesn't need further discussion, but as a moderator I don't mind someone explaining Linux's (and other systems') exposure of the EFI variables and DFCI and what

Re: [oss-security] Microsoft Device Firmware Configuration Interface (DFCI) in Linux efivars directory

Corey Lopez wrote: I have dual boot Windows 11 Home Edition and Debian based setup on my laptop. Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2024.1 Codename: kali-rolling After realizing a security breach on my Kali system I discovered /etc/network/interfa

Re: [oss-security] Update on the distro-backdoor-scanner effort

Vegard Nossum wrote: [...] Hi, Masquerading a shell command as a pkg-config variable definition is trivial (but probably still detectable) since you can just do: foobar=/usr echo hi which AFAIK is a valid pkg-config variable definition but also a valid shell command. You are correct, but mak

Re: [oss-security] Update on the distro-backdoor-scanner effort

Hank Leininger wrote: On 2024-04-27, Jacob Bachmeyer wrote: - Output is manageable; able to rule out all hits not part of the actual xz-utils backdoors as false positives. This is what I would expect: the backdoor dropper appears to have been specifically developed for xz

Re: [oss-security] Update on the distro-backdoor-scanner effort

Hank Leininger wrote: [...] Where we are: main things investigated: - Similar exploitation toolkits / operator-behavior in other packages? [...] - Output is manageable; able to rule out all hits not part of the actual xz-utils backdoors as false positives. This is what I would expe

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

Matt Johnston wrote: On 2024-04-17 10:25 am, Jacob Bachmeyer wrote: see that particular slowdown? (Not the backdoor initialization making sshd take longer to start up---a running sshd taking longer to reject a session for a nonexistent account, unless Andres Freund forgot to tell us that he

Re: [oss-security] Make your own backdoor: CFLAGS code injection, Makefile injection, pkg-config

Vegard Nossum wrote: Hi all, Given the recent xz/sshd backdoor, I wanted to try to think more like an attacker and build my own backdoor. To start off, I've chosen the Linux kernel as the target for the attack, and I want to do it without changing either the kernel source code or any release ta

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

Solar Designer wrote: [...] xz backdoor analysis More findings were made about the backdoor's functionality, notably as published on April 6 by blasty, who discovered that besides triggering system() the backdoor also allows interactive sessions: https://twitter.com/bl4sty

Re: [oss-security] Analysis on who is Jia Tan, and who he could work for, reading xz.git

Alejandro Colomar wrote: Hi Jacob, Thanks to your script, I've found a mistake in my analysis of the timestamps. Interesting. I am very happy to have helped clear the air. The commit dates in +0200 recently seem to be because Jia Tan rebased some commits from Lasse, and used --committer-

Re: [oss-security] Analysis on who is Jia Tan, and who he could work for, reading xz.git

Alejandro Colomar wrote: [...] On Wed, Apr 10, 2024 at 10:26:13PM -0500, Jacob Bachmeyer wrote: [...] First, a factual correction: The hypothesis that "Jia Tan" was actually in UTC+03 seems to have been backwards, since the peak activity overlaps only partially with offic

Re: [oss-security] Analysis on who is Jia Tan, and who he could work for, reading xz.git

Solar Designer wrote: On Wed, Apr 10, 2024 at 05:16:52AM +0200, Alejandro Colomar wrote: I've been researching xz.git to learn about this malicious actor, and who he might have worked for. As a moderator, I reluctantly let this through out of respect for Alejandro's time and knowing th