On Wed, Nov 5, 2025 at 12:13 PM Olle E. Johansson <oej () edvina net> wrote:

On 4 Nov 2025, at 18:59, Art Manion <zmanion () protonmail com> wrote:

On 2025-11-04 04:03, Olle E. Johansson wrote: On 3 Nov 2025, at 19:07, Art Manion <zmanion () protonmail com> wrote:

CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and CVE-2025-12207) mentioned in this thread are not yet disputed and have no comments of this sort in their descriptions. I asked VulDB to mark the dnsmasq CVE IDs as disputed. The VulDB CNA decided to reject the dnsmasq CVE IDs. As part of the Kamailio project I can say that we did just become aware of these CVEs in your email. They do not make sense. Trying to get to the report, the config files used to provoke the issue can’t be downloaded.

We’ve gone back and this was our core developer’s reaction to the mail we got earlier to our security address: "This is clearly spam, imo: vague/generic reporting, no explicit naming of Kamailio ... the email was not sent from the vuldb.com server but from mc20a2201.dnh.net ([185.46.57.114]) -- I would suggest to not clink on the links, they might lead to malware, etc... I understand both sides of this problem. Would it have helped if the VulDB notification included details such as these (from CVE-2025-12207)?

https://shimo.im/docs/vVqRMVMlrycMO63y/read For us that site is not trustworthy. It could be language/cultural issues. One example is that the actual configuration files for some reason can’t be downloaded and the error message is in a language I have no understanding of.

Trust is hard. We have to think about this. We get all kinds of strange emails to our security reporting email address so we’re very cautious unfortunately.

How can we create some kind of trust system so that any open source developer - from one person projects to large projects with massive funding - know that a report is worth reacting to?

/O - Art

It seems to be that there is a hidden stage during the PSIRT function that may require its own identification inside the CVE Program (which I assume is the highest source of truth for us at this moment?). And that stage is when a security issue is deemed not enough to become a full CVE, but it is still relevant for awareness purposes. Assigning a CVE ID only to have it disputed or rejected later seems like a process that is confusing and hard to manage.

Disputes have no nuance and once the word is out, the possible damages are hard to revert. Oftentimes they stay perpetually open, and resolutions seem to not give any definitive answer, which adds to the confusion. Most CVE record consumers do not have a way to clearly differentiate and correctly prioritize them.

What if a new ID could be created for these cases, like a lower level CVE, which can help raise awareness, maintain discussion history, and issues could be elevated or degraded to it without them getting stuck at the never ending vendor CVE grinder, but still benefiting from the current CVE infrastructure?

-- Pedro Sampaio | Red Hat Product Security 851525C5A98E9DEB7E650ABDFAC8296FBC674B8F

On 11/1/25 15:35, Russ Allbery wrote: Solar Designer <solar () openwall 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)

Hi Russ,

Russ Allbery <eagle () eyrie org> writes: Solar Designer <solar () openwall 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"? If it makes you feel better, I do not think it is an "ask the Lazyweb" question. I actually had the same question.

There is a recent example in GNU Tar CVE-2025-45582 [1] which describes a situation that has been described in the manual for 15 years. Copying the relevant text from the manual [2]:

When extracting from two or more untrusted archives, each one should be extracted independently, into different empty directories. Otherwise, the first archive could create a symbolic link into an area outside the working directory, and the second one could follow the link and overwrite data that is not under the working directory. For example, when restoring from a series of incremental dumps, the archives should have been created by a trusted process, as otherwise the incremental restores might alter data outside the working directory.

There seems to have been agreement to change this longstanding behavior, but the CVE situation seems to have been handled very sloppily. The CVE was assigned on 2025-07-11, and the GNU Tar mantainers did not know about it until 2025-08-07 when a third party inquired about it on list [3]. Presumably upon scanning a container or something like that.

Collin

[1] https://nvd.nist.gov/vuln/detail/CVE-2025-45582 [2] https://www.gnu.org/software/tar/manual/htmlnode/Integrity.html [3] https://lists.gnu.org/archive/html/bug-tar/2025-08/msg00000.html

Solar Designer <solar () openwall 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"?

It feels like this problem is arising regularly with automated and semi-automated security testing and fuzzing, and there are regular complaints about security "bugs" that the maintainer considers meaningless because they don't cross a privilege boundary in the maintainer's model, and then endless disputes about edge-case usage where no, actually, that is a security boundary.

I don't think the argument over what the security boundary should be in the abstract is winnable; there will always be someone who disagrees. But documentation of the maintainer's intended security boundary is an objective fact about the software maintenance practices. If the maintainer says "if you can write to the configuration file / inject arbitrary command line parameters / control the input to the program, the program will execute arbitrary code and this is by design and I'm not going to change it," this feels like useful information for both users and security researchers. Or even if the answer is that weird behavior in that scenario will be considered a bug but not a security issue, and therefore won't be treated with much urgency, won't result in a new software release when fixed, won't be backported, etc.

One can disagree with the maintainer and try to change the maintainer's mind, but failing that, if you want a different security model than what the software declares it supports, the answer is to use a different piece of software (such as a fork) or enforce the security boundary yourself somehow, not to file a CVE.

It would be really nice if the maintainer could somehow declare this in such a way that CVE issuers could retrieve that declaration and check the CVE report against it, ideally in a semi-automated fashion. I say "semi" because I think a human will have to be involved to some extent, or the expression language problem will be too hard, but it would be nice if automation could take a reliable first cut at filtering things down to the bits a human has to look at.

Beyond the perpetually-discussed case of configuration files, since there are indeed some programs that consider configuration file parsing to be a security boundary and treat failure to safely parse an attacker-controlled configuration file as a security bug, this would also provide a way to represent the difference between (to exaggerate for clarity) a command to do malware scanning (should be runnable on arbitrary untrusted input) and, say, "bash" or "python" (will never be possible to run on arbitrary untrusted input by design).

I can of course stick such a statement in the documentation and the security bug reporting instructions and so forth, and that would be a good start and I'm not doing that in all the places that I should, but if we could agree on a language for representing this, that feels a bit more satisfying. Part of the ongoing problem is a constant fight over definition of terms, so having some pre-defined terms feels useful.

-- Russ Allbery (eagle () eyrie org) <https://www.eyrie.org/~eagle/>

On 2025-10-31 20:00, Solar Designer wrote: On Fri, Oct 31, 2025 at 09:06:09PM +0000, Art Manion wrote:

Does dnsmasq read the config file before dropping privileges? I think so, since dnsmasq needs to know what interfaces and ports to bind to?

Does dnsmasq check that the config file is root-owned and not user- writable? In my brief testing, no.

Can a regular user call dnsmasq with '-C dnsmasqmalicious.conf' and achieve memory corruption under root privileges? Even if it's unlikely to result in code execution, that privilege escalation may qualify as a CVE-worthy vulnerability. 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. About an hour after posting this I slightly regretted it, my line of thinking was along the lines of dnsmasq being setuid (it is not on the systems I have at hand). A agree that some other system that uses dnsmasq should be responsible for managing privilege separation if that system allowed low-privileged users to modify config files that influenced the behavior of privileged programs.

- Art

Hello Stuart,

On 10/27/25 20:45, Stuart Henderson wrote: On 2025/10/27 19:51, Sebastian Pipping wrote: Also, fixes without a CVE will not be backported downstream. That depends on the downstream. I'm happy to learn which downstreams backport security issues without a CVE, in practice. Do you have an example or two?

Thanks and best

Sebastian

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).

Cheers, Moritz

On 2025-10-27 09:34:03 -0700 (-0700), Alan Coopersmith wrote: [...] [...] -- Jeremy Stanley