Just a reminder that these severity ratings, while often directionally useful (a 9.x probably is something you should care about if you run the target software; a 2.x is probably not), the ratings themselves are total horseshit and are running industry joke; literally a Ouija board, starting from a hopelessly ambiguous "calculator" that you run and then apply subtle inputs to to get the score where you want it to be.
> the ratings themselves are total horseshit and are running industry joke
Any further references to this? I’d love to have something I can send around internally. The people running Tenable tend to treat these numbers as gospel.
Well, just pull up a CVSS calculator and start asking yourself questions and playing with it. As a fun game we would have people independently rate bugs on our Slack, mind you these are seasoned information security consultants that have broken a lot of software, and the ratings were hilariously far apart. Ask everyone to rate it low/medium/high/critical and consensus was pretty easy to achieve. Anyway the point is the criteria are quite subjectively. What comes out seems very quantitative, but it’s basically a pile of Jello in terms of how solid it is.
You really should be performing your own risk assessment so you can convert this notional context-free severity rating to your own context-related impact and likelihood to give you your own company risk rating. Ratings over a certain number (to be agree with at board level - in effect your risk appetite) should be treated (risk remediated, removed, transferred to a third party etc etc).
We also do this with pen test reports which suffer the same kinds of issues.
Usually find that sometimes a medium is a critical for us and some times a high is a low for us - based on performing this kind of assessment.
> You really should be performing your own risk assessment so you can convert this notional context-free severity rating to your own context-related impact and likelihood to give you your own company risk rating.
Totally agree, and I do that - check the vulnerability description, see if we’re using that part of the library, etc… it usually works out that we’re not actually affected by whatever the alert is.
I got out of vulnerability management ~10 years ago and moved into other domains where I didn't really work around CVEs and vulnerability reporting. I dipped my toes back in late last year and couldn't believe that basically nothing had changed.
(Just curious) is there something about this that lacks substance? Sure, a CVE rated 8.6 vs a CVE 9.8 may or may not be worse than the other, but is there a better mechanism to communicate severity other than this, or something like "Medium", "High", "Critical", struggling to see your point.
I'm exclusively back on my bullshit about CVSS being a debacle, and hoping that if I whine about it enough, people will stop putting CVSS scores in headlines, because they're meaningless. "Critical" does a fine job.
Ah yes, the ACEI scale: ASAP, Critical, Emergency, and In progress. In Progress being the only thing that actually gets done. The rest is conjecture. ASAP will never get done.
With apologies to Cardinal Richelieu, give me 6 items from the policies of the most functional large organization, and I will find something in them which will hang it.
If you don't see dysfunction, you're not looking closely enough. That's not to say all organizations are equivalently dysfunctional or that we shouldn't strive for better. I'm just saying that "dysfunctional" isn't a damning accusation.
In my mind there are only two factors that matter: the accessibility of the attack vector and the extent of the blast area if the target is compromised.
The funny thing about infosec taxonomies is that actual attacks actively resist classifications like CVSS.
CVSS is generally used on the sysadmin side to figure out what to patch first. Successful attackers generally go after shit that's unpatched. This often means that the most exploited bugs are the ones with the lowest CVSS scores, so new tools and techniques tend to grow around issues that sysadmins consider to not be a big deal.
People eventually catch on that the "no big deal" bugs are getting exploited en-masse, and try to tweak the scoring process, which is why we're on CVSSv3 now with CVSSv4 in the works, and it's just as useless as it's always been.
These ratings are intended to serve as a baseline for the severity of the issue at hand. If you expect a base CVSS score to provide the answer to "how does this affect me" then you need to learn more about CVSS.
Namely, you should be taking the base CVSS score and including the temporal and environment metrics to actually determine your organizational risk. A base 9.x could easily be driven to low based on the access, exploitability, and CIA requirements for the system at hand.
I always use them as a guide for what we should talk about first to then give them our own internal rating. Typically vuln criticality is very system specific.
Context matters a bit. From what i understand its a plugin that's only sometimes used and would typically (but clearly not always) be not exposed to the internet.
So its a serious vuln, but not as serious as say if it was in a component that was always exposed to the internet in the core part of vmware. I guess vulns can always be worse.
How bad it is depends on how you use vmware. I mean regardless, clearly everyone affected should patch.
I'm hopefully preaching to the choir here but please beware that high-visibility flaws often attract fake PoCs. Malicious in the sense "might [also] attack the user" (you!).
Often these will surf on work done by valid PoCs to look credible. GitHub was stuffed with them for the Hafnium Exchange bug, before Microsoft brought down the ban hammer. (At the time there was lots of mewing about "Microsoft protecting their own" and "Microsoft killing free speech" but I wonder if they weren't also interested in stopping the pwnage from these fake exploits, too).
I'm not saying this repo is malicious. This github user looks legitimate and doesn't look like the obviously-created-by-a-bot profiles I've previously seen. Even so I wouldn't necessarily trust ~5000 vendored class files. Play carefully.
It's safe to say that anybody who exposes VCenter directly to the web is practicing poor security. I cannot imagine any scenario where this would be required. I manage a few VxRail/vSphere clusters and everything is behind firewalls and VPNs.
That said, I understand that this vulnerability basically gives root to anyone with VPN access. In our case, pretty much anyone who has VPN access to the cluster already has root on it anyway.
Or anyone that found a small unprivileged point of access in a web app that's on your network somewhere. Now they can escalate to root access to everything.
If you don't use the vCenter plugins in which the vulnerabilities exist (vSAN Health Check, vROPS Manager), it's incredibly easy to mitigate this vulnerability by manually marking these plugins as incompatible: https://kb.vmware.com/s/article/83829
If you're an organisation with vCenter, even if you don't have it 'onto the internet' you're far from safe. Your exposure then is merely every user and every (other) device on your internal network that has routable access to your vCenter.
But yes, exposing highly sensitive tools to a wide, untrackable, and frequently hostile audience is not good practice.
Lots of hosting companies use vcenter for managing their VMs, and if you expose vcenter to your customers, you have a very convenient way to have the powercycle VMs, open consoles and stuff like that.
And if you expose it to your customers, you either have to force them to use a VPN (and support it for even their dumbest users), or you expose it on the Internet.
Not great security wise, but the economics do push you into that direction.
Also, if you look at the vulnerability track record of commercial VPN products recently (some mentioned in this article even), they aren't necessarily any safer to keep publically accessible.
Sadly, it's probably happening more with all the "work from home". I imagine lots of Shodan queries for vcenter right now. Apparently "intitle:id_vc_welcome" returns vcenter servers on Google.
> Even for WFH: just set up a damn openvpn in front of the vcenter server, if you don't have the money for a Cisco Anyconnect appliance. It's not that hard
If your business depends on employees that are working remotely, and you have critical services behind a VPN, your VPN solution is now a critical service too, and should be built and managed accordingly.
Just throwing an OpenVPN host up isn’t enough. If you’re going down that road, you need multiple OpenVPN hosts, each one “hardened” (since they’re internet facing), and a mechanism to deploy the VPN clients (and certificates) to the users. You then need to do this a second time too for an entirely different VPN solution (OpenConnect? WireGuard? StrongSWAN?), in case the first one suffers a vulnerability that you can’t immediately mitigate and instead just needs to be shutdown.
Like most technology solutions, this is only trivial to resolve if you’re operating at a really small scale, all your users are tech savvy, and you don’t treat it as a business critical service.
The moment your business depends on it, it either ceases to be trivial, or becomes a large source of operational risk.
Some people rightly don't trust their 'butcher' or the meat chain of custody that much. We eat shredded raw beef meat here and even I sometimes wince at the idea...
Dear arstechnica, please don't write articles like this, where you make it seem like curl is somehow related or even the cause:
"It can be reproduced using five requests from cURL, a command-line tool that transfers data using HTTP, HTTPS, IMAP, and other common Internet protocols."
I find it quite untasteful to somehow sneak an plug for curl in here at all.
Thinking of: “I will slaughter you”, where Daniel explains how he gets death threats from clueless sysadmins that see that they have been hacked by someone that used curl.
I guess you're right, but in this context it's clear by curl's author's blog post mentioned in my original post, that cause can be easily confused by less technically savy readers.
I am interested in knowing which readers are technical enough to know or care what cURL is, but not technical enough to understand that the vulnerability isn’t in cURL itself.
You consider people sending death threats to developers because they think curl is some evil hacking tool not an "actual problem", despite it already having happened? We sadly share the world with "absolute morons", yes.
(also, how is asking for a change a "war" against the publication?)
I am utterly stunned by the threat which Daniel Stenberg reports on his blog, the link above, frightened actually because before I got very far trying to think of ways to register for a icloud address as a throwaway email account, I realised that the threat was accompanied by no less than screen shots presumably from the same person's phone and if those are from a iPhone I'm pretty sure that the metadata in those images could verify if that's a real active and device and network subscription linked icloud account.
The being HN I expect we automatically presume that everything is spoofed. Unfortunately having received death threats signed by the person's full name and someone identifiable in the media no less, I have to give it the possibility that that is the real person's name and icloud account identity and they simply don't care about anonymity because of having a completely dysfunctional mental condition. That's why this scared me. I'm becoming more and more aware of this kind of recklessness combined with the spectre of violence. Today in London in broad daylight a woman stabbed her victim amid a busy intersection crossing and carried on shouting at the victim "yeah I &ing stabbed you " over and over. Senses of proportion are long missing from broad society and I have started to think that like neurodegenerative diseases by the time we can't cover them up were done for.
Edit : the reason I'm thinking about neurodegenerative diseases I think is because our understanding of social behaviour is rooted in a very brief attention to studying the world when there were simply very many fewer humans around in any way at liberty to act on their individual volition. The scale of our race in the present day I believe already requires a complete re-evaluation of models of civil order.
Nothing about the article implies cURL is responsible for the exploit, only that it can be used to leverage the exploit. It's relevant and good to know, and shouldn't be removed IMO.
It's strange to mention cURL specifically in this context. If the exploit only takes 5 HTTP requests, why not just say "5 HTTP requests"? Why does the article need to mention cURL at all if it's not relevant how those requests are sent? Unless cURL is relevant, but that's now how the article is written.
If they're trying to get across to a non-technical audience how easy it is, then why mention cURL? They're not going to know what cURL is, as evidenced by the explainer following immediately. Why not just say, "5 HTTP requests sent by the command line"?
Right, I understand. My point is that if they're going to mention cURL, but then describe it as "a command-line tool that transfers data using HTTP, HTTPS, IMAP, and other common Internet protocols." why not just say the attack can be executed directly from the command line? Any techincally literate audience will understand that implies cURL (or any other tool!) and an non-technical audience will understand its simplicity, if that is in fact the case.
I still think it's strange to mention cURL specifically in the way they did and agree with the GP. Here's another terrible analogy for the HN archives, but it's kind of like saying, "the smash-and-grab on the jewel store can committed with a Stanley™ 16 oz Curved Claw Fiberglass Hammer" when of course any heavy, handheld object will do.
> why not just say the attack can be executed directly from the command line? Any techincally literate audience will understand that implies cURL (or any other tool!) and an non-technical audience will understand its simplicity, if that is in fact the case.
I mean, the normal way to use curl for this kind of thing is to define the request you want to send in a file and tell curl to read the file. There's no requirement -- or implication -- of simplicity in an attack that "you can execute from the command line"; that description refers to every possible attack. It's meaningless. There's nothing you can do that you can't do from the command line.
It might to you and people in your circle, but that's not the entire audience of the article. I wouldn't assume everyone knows what a Dremel is either.
I understand that it's nothing to do with curl specifically, you understand it, good chunk of HN users do understand it. But general public doesn't really
cURL is used for this purpose all the time, it's perfectly legitimate to mention it in this context, it's only factual.
If you have to censor your content to account for the stupid and the mentally ill (slaughter guy sounds schizophrenic complete with delusions of grandeur and persecution syndrome), you will have to stop posting completely.
What I find very distasteful is your attempt to incite people to harass the author over social media.
I worked briefly at VMware. An exploit like this doesn't surprise me one bit.
We had a company mailing list that people used to email jokes back and forth all the time.
One rather ignorant programmer put a rule on his email where he would get an alert whenever anybody emailed him with a particular word in the subject line. That word happened to get into a rather popular email thread, and in the middle of the thread we started getting complaints from him asking us to change the subject line because his pager was beeping off the hook.
Career limiting move! He took a lot of heat for making poor assumptions.
