[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c54c72ce-35b5-475c-9b9d-3a71a84886ad@gmail.com>
Date: Tue, 28 Oct 2025 19:44:55 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, Hank Leininger <hlein@...elogic.com>
Subject: Re: Questionable CVE's reported against dnsmasq
On 10/27/25 19:15, Hank Leininger wrote:
> [ 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 sshd_config would be bonkers.
> A CVE for an appliance whose CLI allows you to set an arbitrary "banner"
> string and write it to /etc/ssh/sshd_config.d/pwned? Sure!
I think the only time one could argue it is not a vulnerability in
the wrapper is if the wrapper is generating correct configurations
that the parser mishandles in an exploitable way. In that case, it's
very unclear what the wrapper's authors should have done differently.
A simple example would be a shell that didn't parse long single-quoted
strings properly. It's generally considered safe to properly quote a
string and then use it in a shell command, even if the original string
came from an untrusted source.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
