Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Harmless Pi-Hole Bug

kiyell.com

Post reply on HN
Print view View original

21–30 of 48 posts

Re: The Harmless Pi-Hole Bug

#21

Post by ziddoap »

suprjami wrote: post #19
ziddoap wrote: post #4

Earlier 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 would be worse in pretty much every respect. 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 el…

> I can look at a CVE and determine for myself and my organization whether it something we need to care about. 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.

>Except it doesn't work like this.

You'll have to email my bosses that :)

Re: The Harmless Pi-Hole Bug

#22

Post by r3db34rd »

ziddoap wrote: post #4
jeroenhd wrote: post #2

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

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 would be worse in pretty much every respect. 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 el…

[dead]

Re: The Harmless Pi-Hole Bug

#23

Post by suprjami »

ziddoap wrote: post #7
chgs wrote: post #6

Earlier quoted context omitted.

So you are happy to have 1 million cves to look for per year per product? Unless there’s a minimum standard it becomes noise, and the real CVEs are lost.

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

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.

Re: The Harmless Pi-Hole Bug

#24

Post by ziddoap »

jgalt212 wrote: post #17
ziddoap wrote: post #4

Earlier 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 would be worse in pretty much every respect. 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 el…

> I can look at a CVE and determine for myself and my organization whether it something we need to care about. 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…

I'm quite happy with the current scenario and decision tree used to assign CVEs. As it stands right now, it is not "everything" that gets a CVE number.

If they change the decision tree and spelling mistakes start being assigned CVEs, I am sure I will change my mind.

Re: The Harmless Pi-Hole Bug

#25

Post by ziddoap »

suprjami wrote: post #23
ziddoap wrote: post #7

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

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.

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

Re: The Harmless Pi-Hole Bug

#26

Post by jeroenhd »

omoikane wrote: post #11
jeroenhd wrote: post #2

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

In this particular case they probably should have reported it as a regular bug and not as a vulnerability, but I am not sure this generalizes to CVE numbers being meaningless since I am not sure how often it happens.

Most CVE numbers are useful, but there are enough meaningless ones that will set off commercial security scanners to extort a sale to make them unreliable enough that you need to dig into most of them (rather than just assume they're security risks and treat them with the correct priority). Annoyingly, there are also plenty of security bugs that don't make it through the CVE system.

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.

Re: The Harmless Pi-Hole Bug

#27

Post by Fnoord »

suprjami wrote: post #19
ziddoap wrote: post #4

Earlier 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 would be worse in pretty much every respect. 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 el…

> I can look at a CVE and determine for myself and my organization whether it something we need to care about. 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.

A decent security scanner allows you to exclude informational vulnerabilities. When I rolled out Wazuh in an org, it allowed for said function. And I still, personally, wanted to know about it at least once.

Re: The Harmless Pi-Hole Bug

#28

Post by Fnoord »

suprjami wrote: post #23
ziddoap wrote: post #7

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

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.

Re: The Harmless Pi-Hole Bug

#29

Post by Valectar »

There'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 speculatively execute arbitrary code from the input, information could be extracted via endpoint timing using a similar methodology to Spectre or Meltdown, right?

Post reply on HN