Live data from Hacker News

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

seclists.org

21–30 of 54 posts

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

#21
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.

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…

> Is that not a problem with how people are using CVEs, scoring them and attaching value to them

Well, yes, it is. But if that's the way the market is going to game the scoring/value system it's (mis)using, then it behooves a project that wants to be successful to play the same game and push back when the scoring unfairly penalizes it.

Basically dnsmasq doesn't really have much of a choice here. Someone found a config parser bug and tried to make a big deal out of it, so someone else (which has to be dnsmasq or a defender) needs to explain why it's not a big deal.

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

#22
post #19
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'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…

Ironically, software without a long list of CVEs is often the real hot garbage.

Some of it is surprisingly well known by name too!

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

#23
post #4
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…

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 arbitrary injection into the config file…

(I’m amazed at the hot messes exposed with HTTP and SMTP regarding difference in CR/CRLF/LF handling. Proxy servers and even “git” keep screwing this up…)

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

#24

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 qu…

>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 malici…

The developer is too stupid to define the threat model — they’re too busy writing vulnerabilities as they cobble together applications and libraries they barely understand.

How many wireless routers generate a config from user data plus a template. One’s lucky if they even do server side validation that ensures CRLFs not present in IP addresses and hostnames.

And if Unicode is involved … a suitcase of four leaf clovers won’t save you.

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

#25
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…

Ironically, software without a long list of CVEs is often the real hot garbage. Some of it is surprisingly well known by name too!

If you do everything yourself you will avoid a lot of CVEs... for the time being.

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

#26
post #21

Earlier quoted context omitted.

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…

> Is that not a problem with how people are using CVEs, scoring them and attaching value to them Well, yes, it is. But if that's the way the market is going to game the scoring/value system it's (mis)using, then it behooves a project that wants to be successful to play the same game and push back when the scoring unfairly penalizes it. Basically dnsmasq doesn't really have much of a choice here. Someone found a confi…

Why?

What negative thing happens to the dnsmasq project if they just don’t argue about whether or not it’s a big deal.

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

#28
post #26
post #21

Earlier quoted context omitted.

> Is that not a problem with how people are using CVEs, scoring them and attaching value to them Well, yes, it is. But if that's the way the market is going to game the scoring/value system it's (mis)using, then it behooves a project that wants to be successful to play the same game and push back when the scoring unfairly penalizes it. Basically dnsmasq doesn't really have much of a choice here. Someone found a confi…

Why? What negative thing happens to the dnsmasq project if they just don’t argue about whether or not it’s a big deal.

Some product decides not to use it. Someone loses a contract supporting it. Someone doesn't get a job because their work isn't favored anymore.

I think you're trying to invoke a frame where because dnsmasq is "open source" that it isn't subject to market forces or doesn't define value in a market-sensitive way. And... it is, and it does.

Free software hippies may be communists at heart but they still need to win on a capitalist battlefield.

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

#29
post #14

Earlier quoted context omitted.

> 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: Hara…

If you are wasting time wording communication then are you doing it wrong? I imagine the response would be looking at it briefly, seeing if it looks dangerous or reproducible and getting an AI to return a templated "PoC or GTFO" response. The mere existence of a CVE doesn't tell anyone whether a bug is valid or not, and the security reports should be handled in the same way regardless of whether one does exist. For s…

"human communication is easy, just have an AI say 'buzz off' and the conversation partner and other strangers will always respond respectfully, I don't know why so many people complain about lack of spoons or other social issues".

Thanks doctor, you just solved my anxiety.

I broadly agree that having templates does lower the amount of human effort and emotional labor required, but trust me, it's not a silver bullet, even hitting someone with a template takes spoons.

I don't really care that CVEs in theory are apparently entirely without meaning and created for nonexistent bugs, we're talking about the reality of how they're perceived and used.

Like, I'm saying "Issuing garbage such that 100 people have to read it and then figure out what to do is bad, we should instead have a higher bar for the initial issuing part so 1 or 2 people have to actually read it, and 100 people can save some time. We should call out issuing garbage as bad behavior to hopefully reduce it in the future".

You're apparently disagreeing with that and saying "But reading is easy, and the thing is meaningless anyway so this real harm that actually happens is totally fine. We should keep issuing as much garbage as we can, the numbers don't mean anything. It's better to make a pile of garbage and stress the entire system such that no one values or trusts it than to add any amount of vetting or criticism over creating garbage"

idk, I guess we're probably actually on the same page and you're just arguing for arguing's sake because you think you can be a pedant and be technically correct about CVEs. Tell me if I got a wrong read there and you have a more concrete point I'm missing?

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

#30
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?

Post reply on HN