aye..
Dell/EMC still very silent on the impact to their ScaleIO product, I notice.. where customer code will definitely be running on VMs etc. The joys of HyperConvergence, eh
A growing consensus among storage hardware appliance vendors is that, since they don't run external software on their hardware, they don't need to stick performance-hindering patches into their operating systems. Software-defined storage (SDS) and hyperconverged systems vendors do, consultants claim, because they can run …
Bit of a tricky one, tbh.
While most storage appliances aren't literally incapable of running external code, they almost never do. They're rarely logged into. I *can* SSH onto my Netapp and run code on it... but I don't, and even if I was doing so, the code would almost inevitably be supplied by Netapp themselves and the SSH session is password-protected and requires a priv elevation to do anything invasive. We're talking about a once-a-year window of opportunity for the attack, rather than a daily occurrence as with a general-purpose OS.
Risk is always chance*impact, and really, the chance of exploiting meltdown/spectre on a storage appliance is orders of magnitude smaller than on a general-purpose OS. The attack surface is effectively tiny.
On the other hand, if one DID manage to get me to run the code, the nature of the appliances (always on, with security and detailed stats barely monitored) means that bad code could run undetected for months.
With HCI, on the other hand, there's really no argument - patch it, do it now, and don't try and make excuses.
I agree, although it depends on what sort of shell is running. Is it a standard bash shell or is it running some custom application instead, which doesn't allow any access to the underlying OS, let alone uploading code?
If you are sshing into a full bash shell, the supplier will need to provide a patch. If you are sshing into a menu driven configuration program with no ability to upload code, then you probably don't need to patch. To exploit the latter you would first need a zero day buffer overflow of some sort to gain any access to the underlying OS, in which case, Meltdown/Spectre is the least of your problems.
As you say, if there is a patch that affects performance, but you can guarantee that no external code is run on the device and you only log on once a year, you can decide for yourself, whether the risk of not patching is worth it.
Lets be real, if you have been compromised to the point where someone can log onto the management components of your storage array and run arbitrary commands then why on earth would the bother with CPU fiddling malware when they can simply export all your data and VM images and find all the written down passwords and embedded certificates at their leisure on a copy of your data.
To borrow a bit of Douglas Adams (RIP) it saves "all that tedious mucking about" with hacking embedded processors.
It also depends on what access the ssh into the shell gives you. If the only users have system level access (not necessarily root but perhaps same user that all the appliance apps run at) then at that point you've lost. As you and others say meltdown/Spectre is irrelevant as they already have all the access they need. The additional risk of Meltdown is negligible and the cost in terms of performance is high.
Can't this people understand their system could be still vulnerable to insiders attacks, or from other compromised systems inside the network with some kind of access? Or they really believe the only attack vector is a browser pointing to "malware.biz"?
Many successful attacks to valuable payloads aren't made with a single direct attack to the system storing them. I wonder if all they know about attacks is from Hollywood movies.
"Can't this people understand their system could be still vulnerable to insiders attacks, or from other compromised systems inside the network with some kind of access?"
Yes they can. But they can also understand that in such a case taking advantage of Meltdown on the storage layer is the least of their problems. They also understand that the performance cost will be paid all day every day.
The security folks will say that, unless it is ring-fenced absolutely from running external code, apply the Spectre and Meltdown patches. That seems good advice. ®
The business reads "ring-fenced absolutely from running external code" as "inside the firewall". Security folks in many orgs spend their time patiently trying g to explain why the current "yes, but..." excuse doesn't work.