The Harmless Pi-Hole Bug
kiyell.com
kiyell.com
This is just generating CVE numbers for the sake of it.
As it is now, I can look at a CVE and determine for myself and my organization whether it something we need to care about. I’d rather that decision stay in my hands, not someone else’s.
Unless there’s a minimum standard it becomes noise, and the real CVEs are lost.
Trying to ignore the extreme hyperbole here...
I want me or my team to see every security-related flaw affecting the products in our network, yes. That's literally our job.
A CVE like this takes maybe 2 minutes for a junior on the team to mark as no risk.
Because the people that do conduct sophisticated attacks are studying every knock and cranny for these types of things. If they can find it once, they can automate it and find more. And then they move on to the next piece of their puzzle of "what can I do from here?"
A lot of this can/should be boiled down to: are our updates and mirrors current?
One selects an OS vendor/distribution explicitly to make this kind of thing their ~problem~ responsibility. They gave me "foo", they can fix it.
There's usually no problem because nobody builds everything from upstream sources. The security vendor yells at me and the OS vendor about discoveries in something they never packaged.
Each distribution gets sufficiently involved that I refuse to mind most CVEs. Eternally grateful my current role allows me to drop this charade
My CVSS score for this is as follows:
CVSSv3.1:AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L (I said "Low" integrity issues, and "Low" availability issues, since I don't know if the DOS issue is real)
That reads out to a "Medium" CVE.
I have, in the past, worked with some banks, and they want all 4+ CVSSv3 CVEs enumerated and either remediated or for a plan to be in place to remediate them.
Maybe you're significantly better than I am at this, but I am hesitant to look at any CVE and say it's not a problem with how I have configured my software. Unless I have really deeply looked into the issue, I get really nervous saying a CVE is not going to affect my software.
If you want to dedicate staff to reviewing useless garbage issues you do that, go and review every issue logged against other non-commercial software.
The rest of us have a job to do.
I'm not sure why you are being hostile about it, but okay.
Obviously you feel very strongly about the subject. You should engage with MITRE and encourage them to reconsider their current CVE inclusion decision tree.
I also wonder how the attacker got access to Bob's home network in the first place?
If only he had the chance to focus on actual important security issues instead of constant notifications about useless noise like the temperature of his Pi-Hole.
Hmm, anything like this can be used as part of side channel if an attacker is able to influence the temperature of Bob's RPi.
That's already the case now, since there's no perfectly objective way to decide whether a bug is even security related or not.
This is just an example of where that already existing subjective distinction was applied in a way that not everyone agreed with. It's an unavoidable problem that is going to happen once in a while.
It doesn't mean that CVEs are useless and it doesn't necessarily mean we need to be more liberal about what warrants a CVE either.
Sure, you are right that a line already exists. However, that line basically boils down to "could this bug conceivably affect security". The decision tree is 4 questions long -- very simple.
What I am opposed to is someone else answering "yes, this could conceivably affect security" and deciding on my behalf that I don't need to worry about it. That is a line for me (or someone who knows the organizations infrastructure, risk tolerance, etc.) to draw.
So we're back where we started. It's still subjective, how much you should "conceive the possibility", when it doesn't appear to actually be there.
Yes, but one can envision a scenario where everything gets a CVE number and you, or members of your team, spend an inordinate amount of time looking up CVE numbers. Then along comes a service that you have to pay for that scores each CVE number for you. Due to any lack of discretion (in a database maintained by "experts"), you'll pay with your time, or your money.
If they change the decision tree and spelling mistakes start being assigned CVEs, I am sure I will change my mind.
Except it doesn't work like this.
A security scanner will include a CVE. People want no red flags on the security scanner. They don't care what the CVE is, they just want red mark go away.
The attitude to accepting useless crap as a CVE is diluting what an important CVE actually is.
You'll have to email my bosses that :)
CVSS has been around since the mid-2000s, so it isn’t as if there’s no way to discern critical vulnerabilities from informational ones.
In a perfect world, you should be able to treat a CVE number in a scan or bug report as something of importance, but in practice you need to filter out the "time protocol allows reading the time" class of CVEs as well. CVEs might as well be links to Github issues if they're treated like this.
Someone's added it to a commercial security scanner recently, so we have a lot of "severity 1" tickets to disable it.
Yes, severity 1 for something that's been there for 25 years. Very important CVE obviously.
The bug here is that unauthenticated users can change a setting that only an administrator should be able to. The maintainers acknowledged the bug and accepted a patch to fix it.
Is changing the temperature unit shown on a dashboard a serious problem? No. But it is a problem and one that could be classified as a security issue.
What's the point of the CVE assignment? Well it creates a public record of this flaw and helps Pi-hole administrators make their own decisions (patch / ignore). It also puts the issue in the hands of other security researchers. For example, is there a possibility of using this vulnerability to conduct a DoS attack? I didn't test this and have moved on to other things but others can.
Setting aside that the vulnerability doesn't actually allow that, isn't this potentially a Spectre / Meltdown vulnerability? This is an unprotected endpoint that conditionally executes code taken from user input. If the branch predictor can be trained to speculatively execute arbitrary code from the input, information could be extracted via endpoint timing using a similar methodology to Spectre or Meltdown, right?
Not to snap at you, but I'm forced to deal with these "what if" scenarios weekly and it drives me nuts. I know the security guys have a job to do, but I feel like half of their job is just trying to drum up scary looking things to justify their employment.