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

11–20 of 54 posts

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

#11

Post by jerrythegerbil »

landr0id wrote: post #10
jerrythegerbil wrote: post #7

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

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

#12

Post by quacksilver »

DiabloD3 wrote: post #4
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…

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

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

#13

Post by akerl_ »

landr0id wrote: post #10
jerrythegerbil wrote: post #7

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

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

#14

Post by TheDong »

quacksilver wrote: post #12
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.

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…

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

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

#15

Post by TheDong »

akerl_ wrote: post #8
TheDong wrote: post #5

Earlier quoted context omitted.

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…

Maybe we should issue a CVE for company vulnerability response processes that blindly take CVSS scoring as input without evaluating the vulnerability.

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

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

#16

Post by tptacek »

TheDong wrote: post #14
quacksilver wrote: post #12

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…

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

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.

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

#17

Post by akerl_ »

TheDong wrote: post #15
akerl_ wrote: post #8

Earlier quoted context omitted.

Maybe we should issue a CVE for company vulnerability response processes that blindly take CVSS scoring as input without evaluating the vulnerability.

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

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.

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

#18

Post by tptacek »

TheDong wrote: post #15
akerl_ wrote: post #8

Earlier quoted context omitted.

Maybe we should issue a CVE for company vulnerability response processes that blindly take CVSS scoring as input without evaluating the vulnerability.

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

I mean, I'm fine with the complaint about vulnerabilities that ambiguously refer to possible code execution, but that is a problem that long predates CVE.

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

#19

Post by rpcope1 »

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

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

#20

Post by quacksilver »

TheDong wrote: post #14
quacksilver wrote: post #12

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…

> 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 some odd reason people have attached value to having your name logged beside CVEs, despite it not telling you anything,

Post reply on HN