Meltdown and Spectre vulnerabilities: Protecting Zscaler Cloud
Three vulnerabilities involving the abuse of speculative execution in modern CPUs were disclosed this week. Technical coverage of these vulnerabilities is available in our security blog. The security blog post will also cover our ongoing effort to protect our Zscaler Internet Access customers endpoints and servers from these potential expoits.
On Jan 4th, 2018 we posted a perliminary trust post stating our assessment that this class of vulnerabilities does not pose a serious risk to our cloud infrastructure or the data that we are securing. This blog post will expand on this statement with additional information we have and actions we performed.
There are several important factors to consider when assessing potential cloud service exposure to this class of vulnerabilities:
- Zscaler runs large parts of its cloud infrastructure and software on dedicated bare metal. We do not share processors or memory with anyone else who may try to escape the virtual environment and access our memory regions to read privileged operational or customer information.
- The attacks can only be executed locally with an attacker running malicious code on the same hardware. Since our execution environment is highly guarded and closed, attackers could not gain access to launch malicious code to begin with.
- We employ extensive controls to prevent a malicious insider from locally executing malicious code on our systems. Jump boxes with auditing and role based controls will detect and log any such activity. These controls are audited and governed by our ISMS processes, policies and procedures.
- There are several cloud infrastructure roles and functions we execute on public clouds or shared infrastructure. All cloud components and the infrastructure they are running on are being actively patched and restarted as patches become available following exact guidance by those service providers. This, combined with strong access controls, will mitigate an attack on our public infrastructure cloud components.
- Any performance penalties resulting from these patches are absorbed and compensated for by our elastic cloud service. You as a customer do not have to worry about appliances slowing down as a result of these security patches.
- Our Cloud Sandbox VM servers contain no sensitive information by design as they are meant to execute potentially malicious software. Furthermore, successful exploitation in a sandbox may prove impossible due to the complexity of exploit and runtime needed for a meaningful compromise. Nevertheless, we are patching our sandbox hypervisors to prevent malicious code in one VM from escaping and reading memory of another VM.
One important topic to highlight is the use of virtualized private infrastructure components by customers. Many of our customers run ZPA connectors, NSS, ZAB and VZENs in their infrastructure. It is important that you update the hosts (hypervisors) to prevent VM escape where another guest on the same host may browse memory regions used by our infrastructure. Only updates to the hosts can protect the guests from these exploits, as a guest OS update will not suffice to protect against another compromised guest. It is the customer’s responsibility to apply updates relevant to their infrastructure. PZENs are not vulnerable as they are running on dedicated hardware and should not allow an attacker to execute arbitrary code on them.