Biggest vuln bombshell in forever and storage industry still umms and errs over patches
Does it run in VMs, containers, systems running external code? Just. Patch. It
Analysis 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 external, customer-supplied software on the same hardware as their software.
For example, a user viewpoint from Martin Glassborow:
Ho hum....the complacency of storage vendors. If you allow— Martin Glassborow (@storagebod) January 15, 2018
sshaccess to your storage appliance and you are running some kind of shell on top of a some sort of standardish OS - I strongly suspect you need to patch for Meltdown/Spectre. I can run code on an Isilon node for example
He goes on to add: "If I can get access to the CLI and upload code, I suspect I can exploit. Many systems are running x86 and 'embedded' Linux, BSD, Windows and allow ssh/CLI access.
"And a huge number of Storage arrays have control/management software often running on embedded x86 servers... that also need patching. What I'm reading at the moment is nonsense from many."
Two SDS companies taking different approaches are Nexenta and Scality. The former admits vulnerability in certain cases, the latter does not.
Dell, HPE, Microsoft and HCI vendor Scale Computing all say their software needs patching. For example, Scale said: "Scale HC3 systems will likely take a small performance hit, but we will be far less impacted than most."
HPE has said patch impact on performance would vary by workload, and has identified vulnerable products in a thorough list:
- StoreVirtual – not vulnerable – product doesn't allow third-party code execution
- StoreVirtual 3000 file controller – vulnerable – further information forthcoming
- 3PAR StoreServ File Controller V3 – vulnerable – further information forthcoming
- StoreEasy 1450, 1550, 1650, 1650E, 1850, 3850 – vulnerable – further information forthcoming
- 3PAR StoreServ 7xxx, 8xxx, 9xxx, 10xxx, 20xxx – not vulnerable – product doesn't allow third-party code execution
- 3PAR StoreServ Service Processors – not vulnerable – product doesn't allow third-party code execution
- XP7 Gen1 and Gen2 SVP and MP – not vulnerable – product doesn't allow third-party code execution
- StoreOnce products – not vulnerable – product doesn't allow third-party code execution
- MSA products – not vulnerable – product doesn't allow third-party code execution
- SimpliVity – fix under investigation
- HyperConverged 250 and 380 – fix under investigation
Nexenta software running in virtual machines or containers is vulnerable.
Software-defined – indeed, software-only – storage supplier Nexenta's VP for marketing and channels, Don Lopes, said: "We're indeed aware of the Spectre and Meltdown bug. As you know, to exploit these hardware vulnerabilities an attacker must have the ability to run software directly on the target system. Contrary to compute platforms or hyperconverged solutions, our products are delivered as closed software appliances and do not allow running third-party software to run on them.
"Due to this, they aren't exposed to exploits. In the cases where our software is run as a VM or a Docker container, we do recommend that customers patch the underlying OS and hypervisors.
"We provided these details and have spoken to a number of our customers and partners who have accepted and are happy with our communication."
Object storage supplier Scality's chief product officer Paul Speciale said: "Scality has not taken a public position on this microprocessor and potential virus issue. We also haven't, to date, had any inquiries about it from our customer base. Our understanding is that while there haven't been any exploits from such viruses as of yet, the threat is mainly to mobile and laptop devices that are directly connected to the public internet, and have access to the root user of the operating system.
"In contrast, the Scality RING software is in nearly all cases deployed in our customers' secure data centres. This means our software is behind the multiple layers of firewalls and security devices, and accessed only by customer applications versus direct access on the internet. This insulation means we are much less susceptible to outside malicious access.
"While we do deploy on standard x86-based servers, we don't present a general-purpose server to the outside world. For example, the RING restricts access to only the necessary network ports needed for operations. We also have our own software stack virtualizing the underlying hardware, and our own management software stack."
Pure Storage Purity Run
Purity Run is a facility on Pure Storage arrays to enable customers to run their own code on them. Does that require the Purity OS to be patched?
A spokesperson told us: "We're exploring this. Keep in mind that our storage arrays are not directly susceptible, and only a small subset of customers are running third-party code within Purity Run, which we released last year.
"We know who all of these customers are and have already contacted each of them personally. We would expect no impact on non-Purity Run storage performance and minimal impact on Purity Run performance for Spectre mitigations.
"We'll be working to help users assess Meltdown mitigations for any guest environments or apps they are running within Purity Run, though the same updates would be necessary regardless of whether they are running on a virtualized platform or bare metal."
What should you do about your software-defined storage and Spectre/Meltdown? 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. ®