[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa732776-855f-42e8-b645-b2c3f13413f2@gmail.com>
Date: Sat, 1 Nov 2025 17:12:42 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, Russ Allbery <eagle@...ie.org>
Subject: Re: Questionable CVE's reported against dnsmasq
On 11/1/25 15:35, Russ Allbery wrote:
> Solar Designer <solar@...nwall.com> writes:
>
>> I don't think a "check that the config file is root-owned and not
>> user-writable" would be relevant since a maybe-relevant threat model
>> involves config files intentionally created by other software such as a
>> web UI, which would set permissions such that the file is processed, and
>> since such checks are uncommon and the lack of them does not mean the
>> software supports untrusted config files.
>
>> Other than that, I see that this gets tricky for a CNA to evaluate
>> without input from the maintainers, so I may have been unnecessarily
>> harsh on VulDB.
>
> This is a bit of an "ask the Lazyweb" question since I have done only
> minimal research, but is there any way for me to declare, as the software
> maintainer, what I consider to be the security boundaries of the software
> in a way that can be at least partially machine-readable? I know there are
> tons of modeling languages for *building* software, imposing or checking
> access control, etc., but is there a way for me to *label* a free software
> project to communicate information such as "edit access to the
> configuration file is arbitrary code execution by design"?
Even this gets tricky. For instance, it is trivially unsafe to pass
untrusted input to a shell *without properly escaping it first*.
However, if the untrusted input is properly escaped, then it is the
shell's job to process the data correctly. The same goes for kernel
command lines in libvirt XML configurations, SaltStack reactor YAML,
Vim script command arguments, and almost certainly many, many more
situations that I am not even aware of.
What all of these situations have in common is that the data being
parsed is a serialized data structure. It is safe to use untrusted
input for some parts of the data structure but not for others.
The software that creates and serializes the data structure is
responsible for ensuring that the serialized data structure is valid.
It is the job of the consumer of the data structure to correctly
handle parts that might reasonably come from untrusted input.
In the dnsmasq case, it definitely isn't okay to pass a fully
untrusted config file. However, I think it is reasonable to allow IP
or MAC addresses and certain DHCP option values to come from sources
that are less than fully trusted, provided that they are valid and
properly encoded.
In the end, this does come down to the maintainer, but it's not as
black and white as "do not pass untrusted input". It's "these fields
cannot have untrusted input at all, but these other fields can have
anything that meets conditions XYZ, and yet other fields can have
anything at all so long as it is properly encoded."
--
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.
