HCI vulnerability

chinchillaking — Wed, 04 Jun 2025 10:26:42 GMT

Hello,

After use Nessus scan HCI 1.8P1 and discover below vulnerability, but the "Remediation" did not mention fix the issue. Could HCI 1.9 fix below vulnerability? If did not patch fix, could management node setup firewall ACL allow dedicate hosts access?

https://security.netapp.com/advisory/ntap-20191017-0001/
CVE-2019-11068

https://security.netapp.com/advisory/
CVE-2019-14287

CVE-2020-10029

CVE-2020-26116

CVE-2021-3156

CVE-2019-5094

CVE-2020-13817

CVE-2020-15025

CVE-2020-1971

CVE-2020-1752

CVE-2021-3156

Best regards,

Chung

Re: HCI vulnerability

kryan — Wed, 28 Apr 2021 18:51:56 GMT

Hello,

Mitigations (fixes or workarounds) are expected for all affected Full Support products. Advisories are updated with first fixed releases when they become available for use.

I am unsure if it is possible to configure the firewall on the management node - I'd recommend a support case to confirm.

Re: HCI vulnerability

elementx — Sat, 01 May 2021 06:49:49 GMT

Oftentimes such scans are just "security spam" and report all sorts of things. Many a time it's completely irrelevant to our use case because we don't run eCommerce portals but API services for admins and vCenter/K8s.

For example, let's take a look at the first two CVEs:

1) CVE-2019-11068 - libxslt - I don't see how any of that applies to NetApp HCI or SF environments. "xsltCheckRead can return -1 for a crafted URL that is not actually invalid and is subsequently loaded". Users are administrators. If someone could show me how one admin with limited permissions can become another admin, I'd be interested. Otherwise, I don't see how this matters.

2) CVE-2019-14287 - sudo vulnerability. First, there are no users on mNode (or SolidFire nodes) except admins, so there's no harm in a sudoer becoming root. Second, the vulnerability - as per example exploit in the CVE - doesn't do anything (see below). Third, you can become root by simply switching to root - the only user there is (admin) is supposed to be able to become root.

Yes, you can limit IP access and NetApp HCI at least recommends to put mNode on a Management VLAN when deploying, so that only admins can access mNode in the first place. If your Mgmt node was on own LAN, exposed only to selected admins and vCenter, for example, it wouldn't get scanned in the first place.

But many users don't do that because it's "inconvenient", so vCenter, SolidFire MIP(s) and mNode MIP are all made accessible to VM Network.

If you haven't done that, you can move mNode to another network, although that may not be possible without reinstalling it (or reconfiguring, but there are no KBs for that as far as I know), or use other approaches such as iptables on mNode.

Because of Docker, there's a lot of rules already configured, so you'd have to be careful to just add additional rules that drop access to HCC/mNode management IP/port to all, and allow it to IPs that need access (which could be a handful, depending who and what needs access to that IP). These rules may need to be redeployed after mNode VM is redeployed or upgraded.

Another way is to install a secure proxy and allow access to mNode only to that proxy IP, and deal with access control on the proxy.

mnode ~ # iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-INGRESS all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere

[...]

topic Re: HCI vulnerability in SolidFire and HCI

HCI vulnerability

Re: HCI vulnerability

Re: HCI vulnerability