Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

seclists.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#41

Post by ohdeardear »

ekidd wrote: post #3
tptacek wrote: post #2

Why does it matter? I know the answer and this is a philosophical complaint, but the purpose of CVE is simply to make sure that people are talking about the same bug, not as a certification of importance or impact. In this particular case, the poster is complaining that 3 CVEs were assigned for memory corruption vulnerabilities reachable only from the dnsmasq configuration file. I didn't read carefully, but the presu…

I suspect the big problem here is thinly-stretched volunteer maintainers. I am very sympathetic to the idea that all memory corruption bugs should be fixed systematically, whether or not they're exploitable. It works well for OpenBSD. And, well, I wouldn't have leaned into Rust so early if I wasn't a bit fanatic about fixing memory corruption bugs. But at the same time, a lot of maintainers are stretched really thin.…

[dead]

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#42

Post by procaryote »

Kiboneu wrote: post #9

Several issues seem to be getting mixed up. The first issue being raised is that replacing the configuration file shouldn't count as a vulnerability. Usually I'd agree, but the fact that it causes memory corruption from user input warrants at least a low severity report. If we can't prove that a vulnerability is exploitable, we have to keep our assumptions minimal. If the memory corruption vuln is provably unexploita…

Assuming it's AI slop, considering that there's been an upswing of AI slop CVE reports seems pretty reasonable.

However, it doesn't necessarily matter if it's submitted by an incompetent human, a malicious human, or is AI slop. The end effect of wasting time on a non-vulnerability is the same

In a world where generating AI slop is cheap, the standard should probably be that the person submitting a vulnerability needs to prove it is a vulnerability, and probably that they're a person. Having the person receiving it prove it isn't won't scale

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#43

Post by phicoh »

b112 wrote: post #40
rpcope1 wrote: post #19

Earlier quoted context omitted.

I've had to generate "bill of materials" for software I've shipped, and often certain end users will beat you over the head for "vulnerabilities" even if they're a low CVSS score or do not apply to your own code. I get the resistance to wanting CVEs for everything, as regardless of the initial intentions, there's a LOT of people/enterprises that just see "oh shit there's a CVE, the whole thing is garbage, we're not g…

I think what's happening here is, people don't have time to assess. And frankly, can you blame them? A person might be implementing dozens or hundreds of pieces of software from multiple vendors. Now there are CVEs on their radar. They have to deal, and assess. What do they do? Do a deep dive on every CVE, including looking at code, validating what the CVE represents, and assessing security risk org wide, no matter h…

As an open source software vendor I can say two things: 1) The CVE system allows vendors to deny CVEs that relate to their product. I don't know the exact rules, so I don't know if it applies in this case. We take anything that can crash our software seriously. 2) For users without a support contract, your priority does not automatically become out priority. If you want your issues fixed then make sure we have the money to do so. Just because you got a free download doesn't give you any rights to support.

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#44

Post by masklinn »

masklinn wrote: post #37
rpcope1 wrote: post #19

Earlier quoted context omitted.

I've had to generate "bill of materials" for software I've shipped, and often certain end users will beat you over the head for "vulnerabilities" even if they're a low CVSS score or do not apply to your own code. I get the resistance to wanting CVEs for everything, as regardless of the initial intentions, there's a LOT of people/enterprises that just see "oh shit there's a CVE, the whole thing is garbage, we're not g…

Yup, and people get real stupid with it too. I’ve seen people request an update to fix redos vulnerabilities in a go package using the stdlib only. Because some time some where a bot flagged the regex and a CVE was opened with no consideration that it was nonsensical. You explain that the CVE makes no sense, and you’re met with the response that “ok but did when”

*fix not did (damn you autocorrect)

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#45

Post by blablabla123 »

If you ever open up a CVE calculator you'll see pretty clearly that the calculation is in isolation, as part of a chain.

Sure, CVE isn't optimal but virtually no model is. It's the whole point basically to provide a simplification of reality to be able to reason about it.

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#46

Post by elnerd »

BobbyTables2 wrote: post #23
DiabloD3 wrote: post #4

Earlier quoted context omitted.

CVEs, however, do get scored according to CVSS, and they are often extremely hostile and live in fantasy land. CVEs also cannot be denied by projects, and are often used as an avenue of harassment towards open source projects. I agree with the poster on that mailing list, this is not, nor should be, a CVE. At no point can you edit those files without being root.

It gets blurry at times though. Imagine a router has a web/cli interface for setting the DHCP server’s domain name. At some point the users’s data is forwarded to a process exiting the root-owned file. Hypothetically, If a vulnerability in the parsing of such from the config could be exploited from the end-user, that would certainly matter. And these things always seem to be one step away from bugs that allow arbitra…

Just because you cannot see how a vulnerability can be exploited does not mean that others can. As you describe, people seem to assume that the only way the config file ends up on the server is «physically» editing it.

An anecdote: I have been struggling with exploiting a product that relies on MongoDb, I can replace the configuration file, but gaining RCE is not supported «functionality» in the embedded version as the __exec option came in a newer version.

A parser bug would be most welcome here.

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#47

Post by xx_ns »

I pentest network devices (amongst other things) for a living, and the way these usually work is that they have dnsmasq running in the background and to accept user config values, templating is used to generate dnsmasq-specific configuration files which are then fed into dnsmasq. I cannot overstate how common this method is.

Some devices do this more securely than others. If you're able to inject newlines, it's highly likely that you can already achieve command execution by injecting directives. I wrote a bit about this technique here: https://blog.nns.ee/2025/07/24/dnsmasq-injection-trick/ (sorry for the self-plug). I think it's up to the device vendor to do this securely and not a concern for dnsmasq.

However, in this case, I feel like the concern is elsewhere and not the sole responsibility of the device vendors. Even if the vendor does templating securely, the vulnerable config options could still trigger the bug in dnsmasq itself and give some advantage to the attacker. Assuming the vulnerabilities themselves are legit, I'm finding it difficult to classify these issues as "bogus".

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#48

Post by b112 »

phicoh wrote: post #43
b112 wrote: post #40

Earlier quoted context omitted.

I think what's happening here is, people don't have time to assess. And frankly, can you blame them? A person might be implementing dozens or hundreds of pieces of software from multiple vendors. Now there are CVEs on their radar. They have to deal, and assess. What do they do? Do a deep dive on every CVE, including looking at code, validating what the CVE represents, and assessing security risk org wide, no matter h…

As an open source software vendor I can say two things: 1) The CVE system allows vendors to deny CVEs that relate to their product. I don't know the exact rules, so I don't know if it applies in this case. We take anything that can crash our software seriously. 2) For users without a support contract, your priority does not automatically become out priority. If you want your issues fixed then make sure we have the mo…

You don't owe anyone anything when free.

However, your reputation does depend upon treating security seriously. It's 2025, not 2005.

So one should indicate "this is a hobby, and I have no time to deal with this" if so. Fair enough!

However, if you have people paying for support, or you want them to see your software and become clients, or you do a project to showcase your skills?

Security front and centre.

My list of helpfuls, in my prior post, actually helps a project maintainer reduce unnecessary queries.

Think of a CVE list as a FAQ.

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#49

Post by ValdikSS »

xx_ns wrote: post #47

I pentest network devices (amongst other things) for a living, and the way these usually work is that they have dnsmasq running in the background and to accept user config values, templating is used to generate dnsmasq-specific configuration files which are then fed into dnsmasq. I cannot overstate how common this method is. Some devices do this more securely than others. If you're able to inject newlines, it's highl…

Kubernetes do that as well

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#50

Post by phicoh »

b112 wrote: post #48
phicoh wrote: post #43

Earlier quoted context omitted.

As an open source software vendor I can say two things: 1) The CVE system allows vendors to deny CVEs that relate to their product. I don't know the exact rules, so I don't know if it applies in this case. We take anything that can crash our software seriously. 2) For users without a support contract, your priority does not automatically become out priority. If you want your issues fixed then make sure we have the mo…

You don't owe anyone anything when free. However, your reputation does depend upon treating security seriously. It's 2025, not 2005. So one should indicate "this is a hobby, and I have no time to deal with this" if so. Fair enough! However, if you have people paying for support, or you want them to see your software and become clients, or you do a project to showcase your skills? Security front and centre. My list of…

What started this is a case where you have to put weird stuff in a config file to trigger the CVE. If the people behind dnsmasq don't get paid or not enough, then it is perfectly fine if this is not a priority.

We have a very popular product, lots of use in what is really the foundation of the internet and almost no support contracts.

So you can turn the argument around, if you are not paying for software, consider it a hobby project. Feel free to report and issue and create a ticket. But don't expect anything to happen. And don't complain on mailing lists how your issue is not taken seriously. Just fix the issue yourself or switch to a different product.

Post reply on HN