6 ms·
CVE-2020-19909 is everything that is wrong with CVEs
- hackermatic 3y ago@dang Title filtering may have stripped out the CVE number, which is important context in the original title: "CVE-2020-19909 is everything that is wrong with CVEs"
- tedunangst 3y agoI mean, CVEs are everything wrong with the system is not inaccurate either.
- dredmorbius 3y ago@dang is a no-op: <https://news.ycombinator.com/item?id=36526450 https://news.ycombinator.com/item?id=36526450> Email corrections to mods at hn@ycombinator.com. (I've done so in this case.)
- extraduder_ire 3y agoIt does usually prompt someone in meatspace to shoot off the email, not that it's a good thing to rely on that.
- dredmorbius 3y agoThere is that. What I'd prefer is that people note the problem, email mods, and note that they've done so. Which is my standard practice.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- galkk 3y agoPriority seem to be already downgraded to low, at least in Ubuntu: https://ubuntu.com/security/CVE-2020-19909 https://ubuntu.com/security/CVE-2020-19909 but in the original site it's still critical https://cve.report/CVE-2020-19909 https://cve.report/CVE-2020-19909 Hard to imagine how that could lead to any security compromise, the seemingly randomly assigned criticality is certainly unpleasant. Could it be that it was detected by "automated source code" and "website vulnerability" reports, when the tools very often assign HIGH, CRITICAL to random issues that aren't the problems
- tedunangst 3y agoAllegedly every report and score is reviewed by a human to determine accuracy.
- arp242 3y agoAllegedly some people are not very good at their alleged jobs. But even with the best people, mistakes do happen; sometimes as banal as clicking the wrong button or mixing up two tabs.
- tedunangst 3y agoThe curl project seems regrettably susceptible to mistabbing.
- RicoElectrico 3y agoThe pinch-hitter syndrome: https://statmodeling.stat.columbia.edu/2005/01/26/the_pinchhitter/ https://statmodeling.stat.columbia.edu/2005/01/26/the_pinchh...
- cratermoon 3y agoI'd say it's more like a manifestation of the neurology of humans: we are very bad at catching rare occurrences in stream of repeated events. Unless they somehow stand out from the rest, our brains aren't wired to notice them.
- kseifried 3y agoHttps://gsd.id/
- upon_drumhead 3y agoIs this a case of https://xkcd.com/927 https://xkcd.com/927 ?
- yawaramin 3y agoLooks like the CVE grading people had their own overflow problem.
- upon_drumhead 3y agounderflow in this case
- deleted 3y ago[deleted]
- smsm42 3y agoAs far as I know, there's no "CVE grading people". The submitter of the CVE decides on the severity. You probably can appeal to MITRE folks if it's hilariously inaccurate but I think that's how it mostly works.
- candiddevmike 3y agoI keep getting emails from India-based "ethical hackers" who ran a vulnerability assessment against some web property and sent me the results. Then they ask for payment. I keep reporting them to Google (Gmail IDs) but they keep landing in my inbox.
- Schnitz 3y agoYup, HackerOne has more or less created a cottage industry of "hackers" that file HackerOne bug reports using semi-automated tools like Burp Suite etc. to get bounties.
- userbinator 3y agoThen they ask for payment. Isn't that extortion? I wonder if India has laws that you can point to to make them go away.
- bawolff 3y agoI think it has to have an "or else" to be extortion. If its just, consider giving us a gift if you found this report useful, that doesn't sound like extortion (still obnoxious though)
- throwaway313313 3y agoThey typically do not want to disclose the full vulnerability details prior to you paying them. For the few that we have engaged in back and forth conversation, they typically were just reporting warnings from various opensource website scanners, without completely understanding what they were talking about. That's not to say somebody might discover a new unique vulnerability in the open source software and packages you might be using, except you wouldn't expect them to report it to your company, as some random user on the Internet, when the official projects are on github. Alternatively if they reported a very specific issue regarding software you developed, I'm sure it would get your 100% attention. That's not been my experience so far (knock on wood).
- 3y ago
- userbinator 3y ago9.8 sounds more like an easily exploitable RCE than what is IMHO barely even worthy of being called a bug. But as long as there is incentive for the security industry to inflate their accomplishments, they will.
- woleium 3y agoNice information system you got there.. Shame if something were to .. happen to it.
- deleted 3y ago[deleted]
- boppo1 3y ago>But as long as there is incentive for the security industry to inflate their accomplishments, they will. Can you elaborate on/contextualize this?
- davidgerard 3y agoCVE stands for Curriculum Vitae Enhancement
- tflinton 3y agoWorking for a company that requires triaging critical vulnerabilities within a few days I’ll attest to how many “critical” that are mostly unexploitable due to a variety of reasons. There has to be a better way.
- bawolff 3y agoVuln ratings are totally divorced from reality. Sometimes the super scary ones will be marked as low or medium too.
- Waterluvian 3y agoI’ve also had zealots want to introduce some pretty significant nonsense to CI for these. I enjoyed when that meant the CTO began getting emails about my products having critical vulnerabilities. Except, uh, we don’t ever use a single Django template and whatnot.
- muldvarp 3y agoI don't think summarizing the criticality of a vulnerability as a single number is possible. Many vulnerabilities really are critical, but only to some users of a software that have some feature enabled (that might be disabled by default). The best way to communicate the criticality of a vulnerability is in text.
- deleted 3y ago[deleted]
- darthwalsh 3y agoThe worst is when some build tool has a bad regex backtracking implementation leading to denial of service with bad patterns. Of course the right answer is to just keep upgrading our dependencies... so our build machine doesn't fall into an infinite loop when a hacker rewrites our build scripts?
- tester756 3y agoThis is what I hate about security industry bunch of scanners (scammers too), checkers, brainless check lists instead of pure code analysis. Sure, it is way easier to run some scanners.exe instead of deep dive into code base, understand it and find actual problems
- deleted 3y ago[deleted]
- 1970-01-01 3y agoIt does fall into 2 categories: "on paper" security and "actual" security.
- nyx 3y agoI've seen a bit of discussion lately about EPSS[0], which is a model that tries to take more practical metrics about any given CVE (including pieces of the CVSS, but also things like whether there's a GitHub PoC or if it's up on ExploitDB) and return a real-world exploitability score out of 100. I can't help but imagine something like this is where we're headed, given how counterproductive it can be to make decisions based on CVSS scores... [0]: https://www.first.org/epss/model https://www.first.org/epss/model
- ploxiln 3y agoThe problem is that a measure became a target. Most companies with a significant internet presence and a "cybersecurity" division have a policy of patching all CVEs. They can't understand vulnerabilities, there are too many and it's too hard, so the policy is to buy products that scan for software versions with known CVEs, and require other teams to patch/upgrade them. This is how most of the industry works now. So of course there is now huge motivation to get these CVE things, inflate them, never under-grade them, just in case ... so of course CVEs are becoming more noisy and useless, and many orgs (including my company) are now moving to EPSS. Just give it a few years though, this EPSS will probably degrade just like CVE as it becomes widely embedded in enterprise security processes.
- namaria 3y agoYeah that chimes with my experience. "Cybersecurity" (a name I hate by the way) without threat modelling and analyzing trade-offs is just compliance. There is a lot of bike shedding, cargo cults and general bs "box checking" work. So many players selling "AI" and visuals in the form of overly complicated "scanning" and CVE database querying, which is little more than checking and matching versions, or circular metadata writing and reading. I got in and out of the field in about a year.
- asciii 3y ago+1 I worked in sec analytics and it was just a bunch of ppl sending me excels with cves and devices. Not to mention the team on the other side of the company that deems something critical so now we have multiple tools scanning, feeding garbage data and a bunch of operations folks patching…only to rinse and repeat.
- junon 3y agoPreach. CVEs are ridiculously broken.
- deleted 3y ago[deleted]
- RcouF1uZ4gsC 3y agoActually looking at the fix for this: https://github.com/curl/curl/pull/4166/commits/a42a763ebde64498f699af7938ad815cdea98e2d https://github.com/curl/curl/pull/4166/commits/a42a763ebde64... It seems the code is using a signed long. Unfortunately, in C, signed overflow is undefined behavior. Anything can happen, and you should not assume that it is just benign behavior like wraparound. Undefined behavior, in a seemingly unrelated area, can result in a security issue somewhere else in the program thanks to how C deals with undefined behavior. While I don’t think it is as severe as the CVE indicated, something that triggers undefined behavior in C is not to be dismissed as lightly as the article is doing.
- ronsor 3y agoIn C, almost everything is undefined behavior. I think it's really hard to write a C program without it.
- soraminazuki 3y agoSo anything that is undefined on paper automatically gets a near maximum score? That doesn't seem right. I'm aware there are cases of overzealous compilers removing conditional code based on the incorrect assumption that overflows can never happen, but this doesn't seem to be the case here.
- lifthrasiir 3y agoYou are technically correct, but signed integer overflows are so pervasive in C that compilers only exploit them when ignoring them would be truly beneficial. In the case of LLVM for example signed integer overflows will merely produce a poison value, and won't produce the actual UB if it is either optimized out or only used by instructions that can't produce UBs by themselves [1]. Compilers also tend to use the UB as an excuse to optimize things, not to break things. We only care about the UB because a faulty optimization still can cause breakages. In this particular case the poison value will eventually reach the following condition [2]: /* if retry-max-time is non-zero, make sure we haven't exceeded the time */ if(per->retry_numretries && (!config->retry_maxtime || (tvdiff(tvnow(), per->retrystart) < config->retry_maxtime*1000L)) ) { So let's assume that `config->retry_maxtime * 1000L` was indeed always a poison value---what can reasonable optimizing compilers do? At worst they will probably evaluate the entire condition as false, because it would help the dead code elimination. Compilers can put a nasal demon in that case, but reasonable ones wouldn't. And since `config->retry_maxtime * 1000L` is not guaranteed to be a poison value all the time, this optimization is not even actually possible. The practical effect of this security bug is quite limited. [1] https://llvm.org/docs/LangRef.html#poison-values https://llvm.org/docs/LangRef.html#poison-values [2] https://github.com/curl/curl/blob/c2212c05aa99bb31e4b99b0b66fc1747b7d01be6/src/tool_operate.c#L473-L478 https://github.com/curl/curl/blob/c2212c05aa99bb31e4b99b0b66... (similar for `config->retry_delay`, omitted for brevity here)
- hedora 3y agoI wonder if the severity rating was set by someone using chatgpt. This seems like exactly the sort of mistake it would make, but that a human with even a little domain knowledge would not make.
- sebzim4500 3y agoWe've been getting BS security emails describing 'critical' issues since long before ChatGPT existed. AI does not have a monopoly on stupidity.
- hedora 3y agoIt’s definitely a force multiplier though.
- fbmac 3y ago[flagged]
- fullspectrumdev 3y agoThe process of assigning CVE’s has been comically broken for a while now. It’s somehow simultaneously possible for it to be both possible for a vendor to block valid CVE assignments, and for people to make up bullshit ones like this.
- smsm42 3y agoIt used to be that anybody could issue CVE for anything, which lead to some pretty bad CVEs. But now there's a CNA program in place, and has been for several years, where the organization can register as a CVE source for a product or a set of products, and nobody would be issuing CVEs for those products. Not sure how 2020 CVE even got in the system - you shouldn't be able to reserve 2020 CVE now, so it appears as if somebody got a CVE ID reserved three years ago and just decided for some reason to publish it as curl CVE. Not sure if the current system has any protections against such abuse...
- smsm42 3y agoLooks like cURL team is not in the list of CNAs: https://www.cve.org/PartnerInformation/ListofPartners https://www.cve.org/PartnerInformation/ListofPartners - maybe they should be. The measure of the last resort for bad CVEs is https://cveform.mitre.org/ https://cveform.mitre.org/ as I understand.
- darksim905 3y agoCNA?
- cratermoon 3y agoCVE Numbering Authorities. Not quite a recursive acronym.
- smsm42 3y agoPlease check out: https://www.cve.org/ProgramOrganization/CNAs https://www.cve.org/ProgramOrganization/CNAs