9 ms·

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

55 points by JawsofDeath 11mo ago

tptacek 11mo ago
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 presumption that config file memory corruption bugs aren't vulnerabilities is problematic, because user input can find its way into configurations through templating; it depends on how innocuous the field triggering the bug is.
- ekidd 11mo ago
  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. And many pieces of software choose to trust some inputs, especially inputs that require root access to edit. If you want to take user input and use it to generate config files in /etc, you should plan to do extremely robust sanitization. Or to make donations to thinly-stretched volunteer maintainers, perhaps.
  - ohdeardear 11mo ago
    [dead]
- DiabloD3 11mo ago
  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.
  - quacksilver 11mo ago
    Is that not a problem with how people are using CVEs, scoring them and attaching value to them rather than whether a CVE should be assigned itself. A CVE is simply a number and some data on a vulnerability so that the community knows they are all talking about the same issue Even if you need to be root to edit the files, it still is a deviation from the design or reasonably expected behaviour of that interface, so is still a bug and should still get a CVE. It should either be fixed or failing that documented as 'wont fix' and on the radar of anyone building an application. Someone building the next plesk or cpanel or similar management system should at least know about filtering their input and not allowing it to get to the dangerous config file. Re: Harassment - Can't the project release a statement saying that the bug writeup is low quality and unable to be reproduced? Anyone ignoring that without question and using it as evidence that the project is bad without proof is putting way too much value in CVEs and the fault is their own
    - TheDong 11mo ago
      > so is still a bug and should still get a CVE It's a bug, sure. The V in CVE is for "vulnerability", which is why people treat CVEs as more than just bugs. If every bug got a CVE, practically every commit would get one and they'd be even less useful than they are now. At that point, why not just use commit hashes for CVEs and get rid of the system entirely if we're going to say every bug should get a CVE? > Re: Harassment - Can't the project release a statement saying that the bug writeup is low quality and unable to be reproduced? If your suggested response to a human DoS is "why can't the humans just do more work and write more difficult-to-word-correctly communication", then you're not understanding the problem.
      - tptacek 11mo ago
        But that's not what happened here. These are memory corruption bugs. Probably not meaningful ones, but in the subset of bugs that are generally considered vulnerabilities.
        TheDong 11mo ago
- TheDong 11mo ago
  If someone can template in data, it's a lot easier to just set "dhcp-script=/arbitrary/code" If the person templating isn't validating data, then it's already RCE to let someone template into this config file without careful validation. ... Also, this is a segfault, the chance anyone can get an RCE out of '*r = 0' for r being slightly out of bounds is close to nil, you'd need an actively malicious compiler. While CVE's in theory are "just a number to coordinate with no real meaning", in practice a "Severity: High" CVE will trigger a bunch of work for people, so it's obviously not ideal to issue garbage ones.
  - tptacek 11mo ago
    Like I said, it depends on the configuration field. But people saying "you have to be root to change this configuration" are missing the point. If the argument is "CVSS is a complete joke", I think basically every serious practitioner in the field agrees with that.
  - akerl_ 11mo ago
    Maybe we should issue a CVE for company vulnerability response processes that blindly take CVSS scoring as input without evaluating the vulnerability.
    - TheDong 11mo ago
      > blindly take CVSS scoring as input without evaluating the vulnerability. Evaluating the CVSS score in your own context is the work I'm talking about. It does no one any good to have a CVE that says "may lead to remote code execution", when in fact it cannot, and if the reporter did more work, then you wouldn't need hundreds of people to independently do that work to determine this is garbage.
      - akerl_ 11mo ago
        People being able to collectively analyze a vulnerability instead of having to all do it independently is pretty much the whole reason for having a CVE database, so I'm glad we agree.
- rpcope1 11mo ago
  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 going to accept this/pay you/etc." Basically CVEs are often weaponized in a really counterproductive way.
  - BobbyTables2 11mo ago
    Ironically, software without a long list of CVEs is often the real hot garbage. Some of it is surprisingly well known by name too!
    - Aperocky 11mo ago
      If you do everything yourself you will avoid a lot of CVEs... for the time being.
      - DeepYogurt 11mo ago
        Or get big enough, join the CVE board and just make the rules such that you can hide them forever
  - baby_souffle 11mo ago
    > Basically CVEs are often weaponized in a really counterproductive way. This is inevitable when you boil everything down to a number. When that number refers to a (potentially) costly bug, people shirk critical thinking and just go straight for zero-tolerance. Not ideal but I'm not sure if there's a better way :/
  - masklinn 11mo ago
    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”
- karel-3d 11mo ago
  I will add the version of dnsmasq this applies to is 10 years old, not a current version.
jerrythegerbil 11mo ago
Vulnerabilities can and often are chained together. While the relevant configuration does require root to edit, that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system. There are frivolous CVEs issued without any evidence of exploitability all the time. This particular example however, isn’t that. These are pretty clearly qualified as CVEs. The implied risk is a different story, but if you’re familiar with the industry you’ll quickly learn that there are people with far more imagination and capacity to exploit conditions you believe aren’t practically exploitable, particularly in highly available tools such as dnsmasq. You don’t make assumptions about that. You publish the CVE.
- landr0id 11mo ago
  >that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system. The developer typically defines its threat model. My threat model would not include another application inserting garbage values into my application's config, which is expected to be configured by a root (trusted) user. The Windows threat model does not include malicious hardware with DMA tampering with kernel memory _except_ maybe under very specific configurations.
  - jerrythegerbil 11mo ago
    > The developer typically defines its threat model. The people running the software define the threat model. And CNA’s issue CVEs because the developer isn’t the only one running their software, and it’s socially dangerous to allow that level of control of the narrative as it relates to security.
  - akerl_ 11mo ago
    > The developer typically defines its threat model. Is this the case? As we're seeing here, getting a CVE assigned does not require input or agreement from the developer. This isn't a bug bounty where the developer sets a scope and evaluates reports. It's a common database across all technology for assigning unique IDs to security risks. The developer puts their software into the world, but how the software is used in the world defines what risks exist.
Kiboneu 11mo ago
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 unexploitable, a future code change could surface it as a plausible exploit primitive. It can also point to a section of code that may have been under-speced, and may serve as an signal to pay more attention at these sections for related bugs. Also, it doesn't seem right to assume that the config files will always be under a privileged directory. The second issue being discussed iun the mailing list is that it's LLM slop. While the reports do seem to be AI generated, I haven't seen any response about the PoC failing, but maybe there is a significant problem where a lot of PoCs are fake. So many assumptions. As commander Data may have said today, "the most elementary and valuable statement in security, the beginning of wisdom, is 'I do not know.'"
- procaryote 11mo ago
  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
themerone 11mo ago
Why go through the trouble of exploring such a bug, when you have the ability to just replace the binary with something with a backdoor?
normie3000 11mo ago
How do CVEs get issued? Where do I apply, who makes decisions, and what software is covered by them? I know these questions are technically answered out there on the internet. But I looked into it a couple of years ago after finding a horrible bug in a popular npm package and the answers weren't clear to me. Can a CVE be issued in retrospect?
- gucci-on-fleek 11mo ago
  > How do CVEs get issued? Where do I apply, who makes decisions For most (but certainly not all) projects, you fill out a simple form [0]. I've done it before and it's fairly easy. > and what software is covered by them? All software is covered by someone, usually by the vendor themselves or MITRE. > Can a CVE be issued in retrospect? Absolutely, but it's fairly uncommon. [0]: https://cveform.mitre.org/ https://cveform.mitre.org/
blablabla123 11mo ago
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.
xx_ns 11mo ago
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/ 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".
- ValdikSS 11mo ago
  Kubernetes do that as well
Jon_Lowtek 11mo ago
has anyone tried the PoC for CVE-2025-12198 from that chinese site on a version more recent than rusty? It wants a signup with a mainland china phone number, and i only have a taiwanese fax machine. The affected version 2.73rc6 is quite interesting, because it is from 2015, and it is not the version the relevant code was introduced in, that is even older (guessing 2.62). Why fuzz some random release candidate from ten years ago? Even more interesting v2.77 from 2017 (commits 5614413 and 2282787 to be precise) changed the code and added an (++i == maxlen) check at the place that is being highlighted by CVE-2025-12198 as lacking an (i < maxlen) check. The commit message says it fixed a crash and thanks a friend for fuzzing the config file. Now i am not well versed in heap smashing with C, so don't confuse my lack of skill with an expert opinion, but i have a hard time understanding how that check is circumvented in recent versions of the code. Any explanation would be welcome. But more than that someone should verify if this PoC works in recent versions. As a prerequisite it should be shared internationally.

55 points by JawsofDeath 11mo ago

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 presumption that config file memory corruption bugs aren't vulnerabilities is problematic, because user input can find its way into configurations through templating; it depends on how innocuous the field triggering the bug is.

ekidd 11mo ago
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. And many pieces of software choose to trust some inputs, especially inputs that require root access to edit. If you want to take user input and use it to generate config files in /etc, you should plan to do extremely robust sanitization. Or to make donations to thinly-stretched volunteer maintainers, perhaps.
- ohdeardear 11mo ago
  [dead]
DiabloD3 11mo ago
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.
- quacksilver 11mo ago
  Is that not a problem with how people are using CVEs, scoring them and attaching value to them rather than whether a CVE should be assigned itself. A CVE is simply a number and some data on a vulnerability so that the community knows they are all talking about the same issue Even if you need to be root to edit the files, it still is a deviation from the design or reasonably expected behaviour of that interface, so is still a bug and should still get a CVE. It should either be fixed or failing that documented as 'wont fix' and on the radar of anyone building an application. Someone building the next plesk or cpanel or similar management system should at least know about filtering their input and not allowing it to get to the dangerous config file. Re: Harassment - Can't the project release a statement saying that the bug writeup is low quality and unable to be reproduced? Anyone ignoring that without question and using it as evidence that the project is bad without proof is putting way too much value in CVEs and the fault is their own
  - TheDong 11mo ago
    > so is still a bug and should still get a CVE It's a bug, sure. The V in CVE is for "vulnerability", which is why people treat CVEs as more than just bugs. If every bug got a CVE, practically every commit would get one and they'd be even less useful than they are now. At that point, why not just use commit hashes for CVEs and get rid of the system entirely if we're going to say every bug should get a CVE? > Re: Harassment - Can't the project release a statement saying that the bug writeup is low quality and unable to be reproduced? If your suggested response to a human DoS is "why can't the humans just do more work and write more difficult-to-word-correctly communication", then you're not understanding the problem.
    - tptacek 11mo ago
      But that's not what happened here. These are memory corruption bugs. Probably not meaningful ones, but in the subset of bugs that are generally considered vulnerabilities.
      - TheDong 11mo ago
TheDong 11mo ago
If someone can template in data, it's a lot easier to just set "dhcp-script=/arbitrary/code" If the person templating isn't validating data, then it's already RCE to let someone template into this config file without careful validation. ... Also, this is a segfault, the chance anyone can get an RCE out of '*r = 0' for r being slightly out of bounds is close to nil, you'd need an actively malicious compiler. While CVE's in theory are "just a number to coordinate with no real meaning", in practice a "Severity: High" CVE will trigger a bunch of work for people, so it's obviously not ideal to issue garbage ones.
- tptacek 11mo ago
  Like I said, it depends on the configuration field. But people saying "you have to be root to change this configuration" are missing the point. If the argument is "CVSS is a complete joke", I think basically every serious practitioner in the field agrees with that.
- akerl_ 11mo ago
  Maybe we should issue a CVE for company vulnerability response processes that blindly take CVSS scoring as input without evaluating the vulnerability.
  - TheDong 11mo ago
    > blindly take CVSS scoring as input without evaluating the vulnerability. Evaluating the CVSS score in your own context is the work I'm talking about. It does no one any good to have a CVE that says "may lead to remote code execution", when in fact it cannot, and if the reporter did more work, then you wouldn't need hundreds of people to independently do that work to determine this is garbage.
    - akerl_ 11mo ago
      People being able to collectively analyze a vulnerability instead of having to all do it independently is pretty much the whole reason for having a CVE database, so I'm glad we agree.
rpcope1 11mo ago
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 going to accept this/pay you/etc." Basically CVEs are often weaponized in a really counterproductive way.
- BobbyTables2 11mo ago
  Ironically, software without a long list of CVEs is often the real hot garbage. Some of it is surprisingly well known by name too!
  - Aperocky 11mo ago
    If you do everything yourself you will avoid a lot of CVEs... for the time being.
    - DeepYogurt 11mo ago
      Or get big enough, join the CVE board and just make the rules such that you can hide them forever
- baby_souffle 11mo ago
  > Basically CVEs are often weaponized in a really counterproductive way. This is inevitable when you boil everything down to a number. When that number refers to a (potentially) costly bug, people shirk critical thinking and just go straight for zero-tolerance. Not ideal but I'm not sure if there's a better way :/
- masklinn 11mo ago
  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”
karel-3d 11mo ago
I will add the version of dnsmasq this applies to is 10 years old, not a current version.

jerrythegerbil 11mo ago

Vulnerabilities can and often are chained together. While the relevant configuration does require root to edit, that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system. There are frivolous CVEs issued without any evidence of exploitability all the time. This particular example however, isn’t that. These are pretty clearly qualified as CVEs. The implied risk is a different story, but if you’re familiar with the industry you’ll quickly learn that there are people with far more imagination and capacity to exploit conditions you believe aren’t practically exploitable, particularly in highly available tools such as dnsmasq. You don’t make assumptions about that. You publish the CVE.

landr0id 11mo ago
>that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system. The developer typically defines its threat model. My threat model would not include another application inserting garbage values into my application's config, which is expected to be configured by a root (trusted) user. The Windows threat model does not include malicious hardware with DMA tampering with kernel memory _except_ maybe under very specific configurations.
- jerrythegerbil 11mo ago
  > The developer typically defines its threat model. The people running the software define the threat model. And CNA’s issue CVEs because the developer isn’t the only one running their software, and it’s socially dangerous to allow that level of control of the narrative as it relates to security.
- akerl_ 11mo ago
  > The developer typically defines its threat model. Is this the case? As we're seeing here, getting a CVE assigned does not require input or agreement from the developer. This isn't a bug bounty where the developer sets a scope and evaluates reports. It's a common database across all technology for assigning unique IDs to security risks. The developer puts their software into the world, but how the software is used in the world defines what risks exist.

Kiboneu 11mo ago

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 unexploitable, a future code change could surface it as a plausible exploit primitive. It can also point to a section of code that may have been under-speced, and may serve as an signal to pay more attention at these sections for related bugs. Also, it doesn't seem right to assume that the config files will always be under a privileged directory. The second issue being discussed iun the mailing list is that it's LLM slop. While the reports do seem to be AI generated, I haven't seen any response about the PoC failing, but maybe there is a significant problem where a lot of PoCs are fake. So many assumptions. As commander Data may have said today, "the most elementary and valuable statement in security, the beginning of wisdom, is 'I do not know.'"

procaryote 11mo ago
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

themerone 11mo ago

Why go through the trouble of exploring such a bug, when you have the ability to just replace the binary with something with a backdoor?

normie3000 11mo ago

How do CVEs get issued? Where do I apply, who makes decisions, and what software is covered by them? I know these questions are technically answered out there on the internet. But I looked into it a couple of years ago after finding a horrible bug in a popular npm package and the answers weren't clear to me. Can a CVE be issued in retrospect?

gucci-on-fleek 11mo ago
> How do CVEs get issued? Where do I apply, who makes decisions For most (but certainly not all) projects, you fill out a simple form [0]. I've done it before and it's fairly easy. > and what software is covered by them? All software is covered by someone, usually by the vendor themselves or MITRE. > Can a CVE be issued in retrospect? Absolutely, but it's fairly uncommon. [0]: https://cveform.mitre.org/ https://cveform.mitre.org/

blablabla123 11mo ago

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.

xx_ns 11mo ago

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/ 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".

ValdikSS 11mo ago
Kubernetes do that as well

Jon_Lowtek 11mo ago

has anyone tried the PoC for CVE-2025-12198 from that chinese site on a version more recent than rusty? It wants a signup with a mainland china phone number, and i only have a taiwanese fax machine. The affected version 2.73rc6 is quite interesting, because it is from 2015, and it is not the version the relevant code was introduced in, that is even older (guessing 2.62). Why fuzz some random release candidate from ten years ago? Even more interesting v2.77 from 2017 (commits 5614413 and 2282787 to be precise) changed the code and added an (++i == maxlen) check at the place that is being highlighted by CVE-2025-12198 as lacking an (i < maxlen) check. The commit message says it fixed a crash and thanks a friend for fuzzing the config file. Now i am not well versed in heap smashing with C, so don't confuse my lack of skill with an expert opinion, but i have a hard time understanding how that check is circumvented in recent versions of the code. Any explanation would be welcome. But more than that someone should verify if this PoC works in recent versions. As a prerequisite it should be shared internationally.