On 11/12/25 20:19, Peter Gutmann wrote: [...]

[0] For example modify the code/operating environment to introduce a security vulnerability, I'll let you decide whether this qualifies as impractical, unrealistic, stupid, or several of the above.

Can we call it CVE-Zero?  :-P

-- Jacob

On 10/27/25 17:40, Michael Orlitzky wrote: On 2025-10-27 19:21:54, Moritz Mühlenhoff wrote: On Mon, Oct 27, 2025 at 09:34:03AM -0700, Alan Coopersmith wrote: Among the new CVE's published this weekend were these from the VulDB CNA:

For all three bugs, the documented "exploit" requires "Replace the default configuration file (/etc/dnsmasq.conf) with the provided malicious file." and if you can replace the server's configuration file you don't need to play games with putting invalid contents in to break the parser, but can simply change the configuration directly. The same nonsense also happened for the Kamailio SIP server (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206 and CVE-2025-12207). Config parser exploits are not necessarily bogus. The admin might allow group/ACL edits to the configuration files knowing that it allows group members to torch the service in question, while, at the same time, not trusting those group members to execute arbitrary commands as root.

If the daemon is launched as an unprivileged user (before reading the config file) the risk is minimized, but often that isn't the case when you want to bind to privileged ports or read private keys that are defined in the config file. Allowing partially trusted users to supply private keys is definitely a sensible use-case. I'm not sure if allowing them to supply an arbitrary config file is sensible, but there are cases where a system generates a config file from untrusted input. For instance, I suspect that OPNsense generates dnsmasq and Unbound configuration files from data provided in the web UI. -- Sincerely, Demi Marie Obenour (she/her/hers)

[ Replying to Michael because this is a perfect jumping-off point, not because I'm saying anything he doesn't know. ]

On 2025-10-27, Michael Orlitzky wrote: On 2025-10-27 19:21:54, Moritz Mühlenhoff wrote: On Mon, Oct 27, 2025 at 09:34:03AM -0700, Alan Coopersmith wrote:

and if you can replace the server's configuration file you don't need to play games with putting invalid contents in to break the parser, but can simply change the configuration directly.

The same nonsense also happened for the Kamailio SIP server (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206 and CVE-2025-12207). Config parser exploits are not necessarily bogus. The admin might allow group/ACL edits to the configuration files knowing that it allows group members to torch the service in question, while, at the same time, not trusting those group members to execute arbitrary commands as root. For a particular package/system/deployment, sure. For the dnsmasq package? I don't think the project claims it's safe to make dnsmasq.conf editable by non-root-equivalent users. Heck just use the dhcp-script=... hook along with user=root to keep privs. Or in the case of kamailio, it looks like it has exec, app, etc.

Somebody could, on a per-package basis, investigate config options/syntax, decide if it's safe / try to create a safe wrapper around config-editing, which knows how to lint edits and which parameters are dangerous, or something.

Which works fine until it doesn't. It's like the #2 way to break out of appliances' locked-down custom CLIs or web UI, after simple command injection.

However, in that case it'd be CVEs in the appliance/wrapper thing, "XYZ CLI privilege escalation via malicious dnsmasq.conf edits", great. A CVE in OpenSSH that requires writing to sshdconfig would be bonkers. A CVE for an appliance whose CLI allows you to set an arbitrary "banner" string and write it to /etc/ssh/sshdconfig.d/pwned? Sure!

Thanks,

--

Hank Leininger <hlein () korelogic com> 8428 ED14 5268 C727 0C48 F454 846F 0637 5FEB 1612

Moritz Mühlenhoff <jmm () inutil org> writes: On Mon, Oct 27, 2025 at 09:34:03AM -0700, Alan Coopersmith wrote: Among the new CVE's published this weekend were these from the VulDB CNA:

For all three bugs, the documented "exploit" requires "Replace the default configuration file (/etc/dnsmasq.conf) with the provided malicious file." and if you can replace the server's configuration file you don't need to play games with putting invalid contents in to break the parser, but can simply change the configuration directly. The same nonsense also happened for the Kamailio SIP server (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206 and CVE-2025-12207). GNU Bison got 2 CVEs assigned that are bogus, CVE-2025-8734 and CVE-2025-8733.

The report for CVE-2025-8733 has a stack trace that references files that do not exist in Bison. I'm pretty sure it is some AI hallucination mixing up Gnulib and glibc, since the stack trace looks like an ancient glibc version which had assertions there.

Collin

Virgil 3d project, used by Quick Emulator(Qemu) to implement 3D GPU support for the virtio GPU, is vulnerable to an OOB array access issue. It could occur when parsing properties in parseidentifier().

A guest user/process could use this flaw to crash the Qemu process instance resulting DoS.

Upstream patch: --------------- -> https://cgit.freedesktop.org/virglrenderer/commit/?id=e534b51ca3c3cd25f3990589932a9ed711c59b27

Reference: ---------- -> http://www.openwall.com/lists/oss-security/2017/02/23/20