[HN Gopher] The Harmless Pi-Hole Bug
___________________________________________________________________
The Harmless Pi-Hole Bug
Author : kiyell
Score : 34 points
Date : 2024-08-20 17:41 UTC (5 hours ago)
(HTM) web link (www.kiyell.com)
(TXT) w3m dump (www.kiyell.com)
| jeroenhd wrote:
| 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.
| ziddoap wrote:
| 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 else's.
| chgs wrote:
| 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.
| ziddoap wrote:
| > _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.
| tsumnia wrote:
| I agree with ziddoap here. Not reviewing these minor bugs
| are exactly how we end up with sophisticated attacks
| using simple bugs that leave us arm chair experts
| commenting "How did they even think of this?!?!"
|
| 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?"
| 8338550bff96 wrote:
| That's a good way to get people to turn off security
| scanners
| distortedsignal wrote:
| I don't know that this CVE would be trivial to knock out.
|
| 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.
| suprjami wrote:
| 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.
| ziddoap wrote:
| > _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.
| Fnoord wrote:
| Yeah except Bob, your uncle, is working from home and
| therefore needs to care about his home network security.
| shawnz wrote:
| > 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 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.
| ziddoap wrote:
| > _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 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.
| jgalt212 wrote:
| > 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 by "experts"), you'll pay with your time, or your
| money.
| ziddoap wrote:
| 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.
| suprjami wrote:
| > 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.
| ziddoap wrote:
| > _Except it doesn 't work like this._
|
| You'll have to email my bosses that :)
| Fnoord wrote:
| 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.
| mjlee wrote:
| Not exactly that, someone can change the unit used to display
| the temperature for authenticated users.
| VyseofArcadia wrote:
| Now we just sit back and wait for the side channel attack where
| someone figures out how to use temperature changes to exfil
| data.
| sokoloff wrote:
| https://xkcd.com/1172/
| tomschlick wrote:
| Yeah this is generating CVE numbers for resume clout.
| omoikane wrote:
| 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.
| jeroenhd wrote:
| 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.
| suprjami wrote:
| My favourite is CVE-1999-0524, people can tell the time set on
| your system with ICMP Timestamp messages.
|
| 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.
|
| https://nvd.nist.gov/vuln/detail/CVE-1999-0524
| Valectar wrote:
| 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?
___________________________________________________________________
(page generated 2024-08-20 23:00 UTC)