[deleted]
The Harmless Pi-Hole Bug
31–40 of 48 posts
Re: The Harmless Pi-Hole Bug
#32Earlier quoted context omitted.
> So you are happy to have 1 million cves to look for per year per product? 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.
That's a good way to get people to turn off security scanners
Some reduction might not be so bad. I would love to know how many times I've said the phrase "the version string/CVE is irrelevant because our vendor backports patches"
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
Re: The Harmless Pi-Hole Bug
#33where is the bug tho... the author is unable to do any exploit because the input variable is correctly sanity checked.... again, where is the "bug" or how is this a bug?
Re: The Harmless Pi-Hole Bug
#34This stuff is why CVE numbers are meaningless. "Someone can see the temperature of your server if they can get into your home network" is barely a bug, let alone a security bug. This is just generating CVE numbers for the sake of it.
Yeah this is generating CVE numbers for resume clout.
Maybe this is actually a good thing. Check a few of the cves they found and if it's things like this, you're dealing with a clown. I'd feel ashamed requesting to get a cve assigned for something like that.
Re: The Harmless Pi-Hole Bug
#35There's a lot of discussion here in the comments on whether this can meaningfully be called a vulnerability if you can only "see the temperature of your server". 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 spe…
This is what annoys me about internal security teams. No, this doesn't make us vulnerable because it's in the DMZ, we have ACLs, it's behind a firewall, we have traffic monitoring, process monitoring, MFA, geofences, etc etc. Just because there's a possibility this could be exploited in some convoluted way in a targeted attack doesn't mean all the other walls we have stood up around this are suddenly useless. I'm constantly pestered and forced to waste my time explaining that your little CVE scanner tool is not the end all for our security posture.
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.
Re: The Harmless Pi-Hole Bug
#36Earlier quoted context omitted.
> If you don't assign CVE numbers to every security-related flaw, no matter how minor the flaw may be, you must come up with a way to draw the line on what flaws get CVEs and what ones don’t. 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 th…
> That's already the case now, since there's no perfectly objective way to decide whether a bug is even security related or not. 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 de…
Except that in this case, the answer to that question is no, this could not conceivably affect security. It's the rough shape of something that could, but actually it could not.
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.
Re: The Harmless Pi-Hole Bug
#37Earlier quoted context omitted.
> That's already the case now, since there's no perfectly objective way to decide whether a bug is even security related or not. 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 de…
Except that in this case, the answer to that question is no, this could not conceivably affect security. It's the rough shape of something that could, but actually it could not. 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.
[deleted]
Re: The Harmless Pi-Hole Bug
#38OP here, it's been interesting seeing people's view of this. I wanted to clarify two things.
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.
Re: The Harmless Pi-Hole Bug
#39Earlier quoted context omitted.
Except this isn't a CVE anyone will encounter in the workplace because nobody in their right mind would run Pi-Hole on a Raspberry Pi in a professional setting. It's a waste of time. 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.
Yeah except Bob, your uncle, is working from home and therefore needs to care about his home network security.
I look forward to your explanation of how the temperature of Bob's Raspberry Pi poses a threat to his employer.
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.
Re: The Harmless Pi-Hole Bug
#40where is the bug tho... the author is unable to do any exploit because the input variable is correctly sanity checked.... again, where is the "bug" or how is this a bug?
Behold, professional bug bounty hunters.