Other CPU Side-Channel Vulnerabilities Subscribe to Security Advisories

Friday, December 14, 2018
Tuesday, March 26, 2019
Summary 

Over the course of 2018 and 2019 industry researchers disclosed a variety of side-channel vulnerabilities for contemporary processor technologies in addition to the more notable Meltdown and Spectre exposures. These additional variants of side-channel vulnerabilities share the same exposures as Meltdown and Spectre for A10 products and are separately addressed in this document.

Item # Vulnerability ID Score Source Score Summary
1 CVE-2018-0495 CVSS 3.0 5.1 Med ROHNP - Key Extraction Side Channel in Multiple Crypto Libraries
2 CVE-2018-3615 CVSS 3.0 6.3 Med L1 Terminal Fault-SGX (aka Foreshadow)
3 CVE-2018-3620 CVSS 3.0 5.6 Med L1 Terminal Fault-OS/SMM
4 CVE-2018-3646 CVSS 3.0 5.6 Med L1 Terminal Fault-VMM
5 CVE-2018-3665 CVSS 3.0 5.6 Med Kernel: FPU state information leakage via lazy FPU restore
6 CVE-2018-5407 CVSS 3.0 4.8 Med Intel processor side-channel vulnerability on SMT/Hyper-Threading architectures (PortSmash)
7 A10-2019-0001 A10 Low SPOILER: Speculative Load Hazards Boost Rowhammer and Cache Attacks (i)

(i)Can only affect vThunder deployments on Intel Core CPUs.

 

These vulnerabilities take advantage of weaknesses in the implementation of computer systems using most (if not all) modern processors and Operating Systems (OSs), including those supported by A10 products. They could allow an unprivileged attacker, in specific circumstances, to read privileged memory belonging to other processes or memory allocated to the Operating System (OS) kernel. To successfully exploit these weaknesses and gain access to restricted memory, an attack requires the execution of crafted, custom code on the target device or system.

ACOS products that support the External Health Monitor feature are potentially exposed to misuse of the feature by malicious, Read-Write privileged administrators. Accordingly, A10 recommends limiting access to such critical infrastructure networking equipment to only trusted administrators from trusted administrative networks and hosts as a defense against active exploit of these vulnerabilities and to ensure that only code fully-trusted by the customer is deployed to these products.

A10 products and release families that support this ACOS feature and warrant these administrative considerations include:

Thunder and vThunder ADC, CGN, SSLi, CFW ACOS (4.1.4, 4.1.2, 4.1.1, 4.1.0)
Thunder, vThunder, and AX ADC ACOS (2.7.2, 2.7.1-GR1, 2.6.1-GR1)
Thunder and AX CGN ACOS (2.8.2)

 

A10 aGalaxy and other ACOS products do not support this feature and are accordingly unaffected by these vulnerabilities. These products include:

Thunder TPS ACOS (3.0, 3.1, 3.2)
aGalaxy TPS Centralized Mgmt aGalaxy (3.2)
aGalaxy 5000 TPS Centralized Mgmt aGalaxy (3.2)
aGalaxy ADC Centralized Mgmt aGalaxy (3.0)

 

For all virtualized A10 products, including ACOS vThunder, A10 recommends that customers ensure that their Host-OSs (hypervisors) are updated as necessary to address these vulnerabilities and that their underlying platforms have corresponding, appropriate firmware updates.

In addition, for A10 Lightning ADC and Harmony Controller virtualized products, root-level access to the Local OS shell and Container Management System (CMS) software is available to product administrators. A10 recommends that only trusted administrators likewise be allowed access to these root-level, privileged services to ensure that malicious code which could exploit these vulnerabilities does not enter or become established in virtual instances of these products.

For A10 Harmony Controller Appliance and Hybrid Virtual Appliance products, root-level access to the Host OS shell is also available to product administrators. A10 additionally recommends that only trusted administrators likewise be allowed access to this service to ensure that potentially malicious code from untrusted parties does not become instantiated in these appliances

To improve the ability of customers to manage ACOS devices, in light of these issues and others like them in the future, A10 will harden and enhance ACOS configuration and management capabilities for this feature as described in the Affected Releases section below.

A10 will investigate future side-channel vulnerabilities for potential impacts and will update this advisory as additional information becomes available. As this investigation proceeds, A10 PSIRT looks forward to feedback and questions on these issues. Customers and partners are welcome to contact the A10 Technical Assistance Center (TAC) or their A10 Sales Representatives. Others are invited to contact A10 PSIRT via email.

Affected Releases

The table below indicates releases of A10 products potentially exposed to misuse of this ACOS configuration management feature by malicious, Read-Write privileged administrators and releases that will harden and enhance ACOS configuration management for this feature.

Customers using potentially exposed releases can update ACOS to the indicated resolved release. If the table does not list a corresponding resolved or unaffected release, then no release update is currently available or anticipated.

Releases AffectedReleases Resolved or Unaffected

4.1.4 – 4.1.4-P2

4.1.4-P3

4.1.2 – 4.1.2-P4

4.1.2-P5

4.1.1 – 4.1.1-P9

4.1.1-P10

4.1.0 – 4.1.0-P11

4.1.0-P12

4.0.0 – 4.0.3-P4

4.1.0-P12, 4.1.1-P10, 4.1.4-P3

2.8.2 – 2.8.2-P10

2.8.2-P11 ⁽ᵃ⁾

2.7.2 – 2.7.2-P13

2.7.2-P14 ⁽ᵃ⁾

2.7.1-GR1 – 2.7.1-GR1-Px

2.7.2-P14 ⁽ᵃ⁾, 4.1.0-P12, 4.1.1-P10, 4.1.4-P3

2.6.1-GR1 – 2.6.1-GR1-P16

2.7.2-P14 ⁽ᵃ⁾, 4.1.0-P12, 4.1.1-P10, 4.1.4-P3

(a) Planned.

Workarounds and Mitigations 

General, recommended practices for the administration of A10 products are described in the Summary section above regarding these potential exposures. Other specific workarounds or mitigations are described below.

RESTRICTING EXTENDED HEALTH MONITOR ACCESS

For A10 products with an ACOS 4.1.x release and which are using local database authentication for administration, a workaround is available to restrict administrators’ use of the External Health Monitor feature.

For such configurations, include the following Role-Based Access (RBA) configuration constraint for all ACOS administrators except those sufficiently trusted to ensure that the ACOS system is not exposed to potentially malicious code, either by their malicious use or by compromise of their administrative systems.

1. Enable RBA (if not already enabled)

ACOS(config)# rba enable

2. Apply the constraint for all system-wide (shared partition) administrative users. The CLI example below uses adminuser1 for the username of the account.

ACOS(config)# rba user adminuser1
ACOS(config-user:adminuser1)# partition shared
ACOS(config-user:adminuser1-partition:sh...)#import.health-external no-access

3. Apply the constraint for all Application Delivery Partition (ADP) administrative users. The CLI example below uses adminuser5 and partition-5 for the username and partition of the account; respectively.

ACOS(config)# rba user adminuser5
ACOS(config-user:adminuser5)# partition partition-5
ACOS(config-user:adminuser5-partition:pa...)#import.health-external no-access

4. If the External Health Monitor feature is not used in the A10 product’s deployment scope, stop here.

5. If the administration policy of the A10 product is to only trust the ACOS default (root) administrator account (username admin) in this regard, stop here.

6. Otherwise, remove the constraint for the select administrative user(s) sufficiently trusted for this administrative capability. The CLI example below uses adminuser3 for the username of the account.

ACOS(config)# rba user adminuser3
ACOS(config-user:adminuser3)# partition shared
ACOS(config-user:adminuser3-partition:sh...)#import.health-external write

For partition constrained administrative users:

ACOS(config)# rba user adminuser5
ACOS(config-user:adminuser5)# partition partition-5
ACOS(config-user:adminuser5-partition:pa...)#import.health-external write

 

REVIEWING EXTENDED HEALTH MONITOR CONFIGURATION

External health monitor scripts should be reviewed and audited to ensure their integrity and intended use in the ACOS system. Instantiated scripts can be listed by the show health external ACOS CLI command and inspected individually using the show health external file.ext ACOS CLI command, where file.ext is the of the indicated script files listed.

MONITORING EXTENDED HEALTH MONITOR ACTIVITY

External health monitor activity can be monitored via the ACOS Audit Log. This log can be configured to log events to an external server through the logging auditlog host CLI command. Import operations can be detected on the logging server by filtering for the following strings and reporting match events for administrative review.

  • For ACOS 4.x Systems: import health-external
  • For ACOS 2.x Systems: health external import
Software Updates 

Software updates that address these vulnerabilities are or will be published at the following URL:
https://www.a10networks.com/support/axseries/software-downloads

Vulnerability Details

The following table shares brief descriptions for the vulnerabilities addressed in this document.

Vulnerability IDVulnerability Description
CVE-2018-0495

Libgcrypt before 1.7.10 and 1.8.x before 1.8.3 allows a memory-cache side-channel attack on ECDSA signatures that can be mitigated through the use of blinding during the signing process in the _gcry_ecc_ecdsa_sign function in cipher/ecc-ecdsa.c, aka the Return Of the Hidden Number Problem or ROHNP. To discover an ECDSA key, the attacker needs access to either the local machine or a different virtual machine on the same physical host.

CVE-2018-3615

Systems with microprocessors utilizing speculative execution and Intel software guard extensions (Intel SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.

CVE-2018-3620

Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and a side-channel analysis.

CVE-2018-3646

Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and a side-channel analysis

CVE-2018-3665

System software utilizing Lazy FP state restore technique on systems using Intel Core-based microprocessors may potentially allow a local process to infer data from another process through a speculative execution side channel.

CVE-2018-5407

A flaw was found in the Intel processor execution engine sharing on SMT (e.g. Hyper-Threading) architectures. An attacker running a malicious process on the same core of the processor as the victim process, can extract certain secret information.

The reporter is able to steal an OpenSSL (<= 1.1.0h) P-384 private key from a TLS server using this new side-channel vector. It is a local attack in the sense that the malicious process must be running on the same physical core as the victim (an  openSSL-powered TLS server in this case). But in general any application which branches on a secret value may be affected.

A10-2019-0001

In this work, we are the first to show that the dependency resolution logic that serves the speculative load can be exploited to gain information about the physical page mappings.

We propose the SPOILER attack which exploits this leakage to speed up this reverse engineering by a factor of 256. Then, we show how this can improve the Prime+Probe attack by a 4096 factor speed up of the eviction set search, even from sandboxed environments like JavaScript. Finally, we improve the Rowhammer attack by showing how SPOILER helps to conduct DRAM row conflicts deterministically with up to 100% chance, and by demonstrating a double-sided Rowhammer attack with normal user’s privilege. The later is due to the possibility of detecting contiguous memory pages using the SPOILER leakage.

The leakage can be exploited by a limited set of instructions, which is visible in all Intel generations starting from the 1st generation of Intel Core processors, independent of the OS and also works from within virtual machines and sandboxed environments.

Acknowledgements 

None.

Modification History 
RevisionDateDescription
1.0
December 14, 2018

Initial Publication

2.0
March 26, 2019

Added SPOILER side-channel vulnerability for vThunders deployed on Intel Core CPUs