Tag Archives: Red Hat Enterprise Linux

Responding to the recent ZombieLand 2 TSX Vulnerabilities

These vulnerabilities can only be exploited by attackers who have already compromised a system. Practice standard security precautions and install updates from hardware vendors and for your software (links provided below) when they become available. Resolution for vendors that offer cloud computing will have a more involved decision making process to consider (see below).

Early last week, security researchers disclosed security researchers disclosed further vulnerabilities within Intel’s processors.

How severe are these vulnerabilities?
These vulnerabilities ca be classed as medium severity. An attacker must already have compromised your system in order to exploit these vulnerabilities. This most recent set of vulnerabilities collectively known as ZombieLoad 2 or Transactional Synchronization Extensions (TSX) Asynchronous Abort affect Intel processors produced in the last approx. 2.5 years (August 2017 onwards).

For full technical details of these vulnerabilities, please see this page from Intel and this page from the security researchers. In summary these vulnerabilities according to the researchers allow “a malicious program to exploit internal CPU buffers to get hold of secrets currently processed by other running programs” leading to “these secrets such as browser history, website content, user keys, and passwords, or system-level secrets, such as disk encryption keys” being used by other running programs.

Of particular note are the performance implications for protecting virtual machines. If your organisation is running potentially untrusted code within virtual machines, protecting that environment will incur a performance penalty. You may need to carry out a risk assessment to determine if enabling these performance reducing mitigations outweigh the risk of putting your virtual machines at risk. Nested virtual machines will be most affected by the performance penalty.

How can I protect my organisation and myself from these vulnerabilities?
These most recent vulnerabilities can be mitigated by updating the firmware (defined) of your system. This is sometimes referred to as the UEFI / BIOS (defined) of your system.

They will be made available separately by the manufacturer of your motherboard of your system for servers, desktops and laptops or the motherboard (defined) manufacturer for any custom-built systems you may have. You will have to determine from the updates those vendors issue if they are available for the products that you own.

In addition, operating system vendors and virtualisation software vendors have made patches available (links provided below).

Thank you.


HP Enterprise:

Fedora (referring to the Xen virtual machine (see also below):

Red Hat:













Performance impact to Xen:

Security advisory:

Further information:

VMware Performance Impact Statement addressing mitigations for Machine Check Exception on Page Size Change (MCEPSC) CVE-2018-12207:

Mitigating the Intel SWAPGS Vulnerability

This is medium severity information disclosure vulnerability. An attacker must already have compromised a system to exploit it. Patches from Red Hat, Google and Microsoft are available. Apple hardware does not appear to be affected.

If we look back 2 weeks we saw the disclosure of a vulnerability relating to VideoLAN VLC being performed incorrectly. This week there is an example of how responsible disclosure should be carried out and demonstrates it can work very well.

Red Hat Linux, Google and Microsoft have all issued patches for a newly discovered variant of the original Spectre v1 vulnerability (initially disclosed in January 2018).

The performance impact of the updates is described in the Red Hat advisory in more detail:

The fix for this CVE has shown to cause a minimal performance impact. The impact will be felt more in applications with high rates of user-kernel-user space transitions. For example, in system calls, NMIs, and kernel interrupts.

Early benchmarks for this mitigation show approximately 1% performance penalty:


How does this vulnerability work?
When building a memory address to access computer make use of segment registers (CS, DS, SS, ES, FS, GS). The FS and GS registers are used when the CPU (defined) is in 64-bit mode. The SWAPGS instruction is used on 64-bit entry into kernel code to swap the current user space value of GS with the value intended to be used during kernel operations. GS is used to access kernel data, but it does not validate the values it uses. There are checks during instruction execution to check if a swap to kernel mode is necessary. It is possible for the speculative execution process (attempting to look ahead to improve performance) to mis-judge if a swap is necessary  resulting in a small window of time where the wrong GS is used for memory access leading to disclosure of privileged information.

How can I protect my organisation and myself from this vulnerability?
Earlier this week Red Hat and Google released updates to resolve this vulnerability. Microsoft issued their update silently on 9th July:

Red Hat Linux


Google Chrome OS

Microsoft Windows

Thank you.

Linux TCP SACK Vulnerabilities June 2019

Earlier this week; Netflix’s Cybersecurity team disclosed 3 denial of service vulnerabilities within the Linux kernels (defined) affecting Amazon AWS, Debian, Red Hat, FreeBSD (only 1 vulnerability affects FreeBSD), SUSE and Ubuntu distributions.

If you use Amazon AWS, Debian FreeBSD, Red Hat, SUSE or Ubuntu, please install the relevant vendor updates or implement the workarounds both linked to below.

Why should these vulnerabilities be considered important?
All of these vulnerabilities are remotely exploitable. The most serious of which has been given the name “SACK Panic” (CVE-2019-11477) is most likely to be present/enabled in web servers used to run both large and small business or personal websites. Exploiting this issue will lead to your server crashing/becoming unresponsive. It has a CVSS 3 base score of 7.5 (high severity) and with a low complexity for an attacker to leverage.

The second vulnerability CVE-2019-11478 which can cause “SACK Slowness” is also remotely exploitable but is of moderate severity. If an attacker were to create and send a series of SACK packets it can cause the affected Linux systems to use too much resources (both memory and CPU). FreeBSD is vulnerable to a variation of this CVE-2019-5599.

The third and final vulnerability CVE-2019-11479 is again moderate severity causing high resource usage. In this instance; when an attacker would need to set the maximum segment size (MSS) of a TCP connection to it’s smallest limit of 48 bytes and then send a sequence of specially crafted SACK packets.

The name SACK is derived from TCP Selective Acknowledgement (SACK) packets used to speed up TCP re-transmits by informing a sender (in a two-way data transfer) of which data packets have been already been received successfully.


How can I protect my organisation or myself from these vulnerabilities?
The affected vendors have released updates or workarounds for these vulnerabilities; links to their advisories and recommended actions are provided below.

At this time, it is not known if Apple macOS (which originated from FreeBSD) is affected. It is not mentioned in any of the advisories. Should an advisory be released it will be available from Apple’s dedicated security page.


Amazon AWS:








Updated: 9th July 2019
On the 2nd of July 2019; VMware issued some updates for this set of vulnerabilities that affects it’s products. Further updates are pending. If you use any of the following VMware products, please review this security advisory and apply the updates as they become available:

Container Service Extension
Enterprise PKS
Horizon DaaS
Hybrid Cloud Extension
Identity Manager
Integrated OpenStack
NSX for vSphere
NSX-T Data Center
Pulse Console
SD-WAN Edge by VeloCloud
SD-WAN Gateway by VeloCloud
SD-WAN Orchestrator by VeloCloud
Skyline Collector
Unified Access Gateway
vCenter Server Appliance
vCloud Availability Appliance
vCloud Director For Service Providers
vCloud Usage Meter
vRealize Automation
vRealize Business for Cloud
vRealize Code Stream
vRealize Log Insight
vRealize Network Insight
vRealize Operations Manager
vRealize Orchestrator Appliance
vRealize Suite Lifecycle Manager
vSphere Data Protection
vSphere Integrated Containers
vSphere Replication

Thank you.

Intel Lazy Floating Point Vulnerability: What you need to know

Update: 24th July 2018:
I have updated the list of vendor responses below to include further Red Hat versions and CentOS:

Red Hat Enterprise Linux 6:

Red Hat Enterprise Linux 5 and 7:

CentOS 6:

CentOS 7:


On Wednesday of last week, a further vulnerability affecting Intel CPUs (defined) was disclosed.

TL;DR: Keep your operating system up to date and you should be fine.

What makes this vulnerability noteworthy?
According to Intel’s security advisory; this is an information disclosure issue. Similar to Spectre/Meltdown the flaw is the result of a performance optimization (used when saving and restoring the current state of applications as a system switches from one application to another). A feature known as Lazy Floating Point (defined) Unit (FPU) is used to save and restore registers (defined) within the CPU used to store floating point numbers (non-integers numbers, namely decimal numbers).

The issue is that these registers may be accessed by another application on the same system. If the registers are storing for example results of performing cryptographic equations for a key you have just created or used to decrypt data, the attacker could use this data to infer what the actual key is. The same applies for any type of data the registers store; that data can be used to infer what the previous contents were via a speculative execution side channel.

This vulnerability has been rated as moderate since it is difficult to exploit via a web browser (in contrast to Spectre) and the updates will be a software update only; no microcode (defined) and/or firmware (defined) updates will be necessary. With exploitation via a web browser being difficult; this vulnerability will likely instead be exploited from the victim system (at attacker will need to have already compromised your system).

How can I protect myself from this vulnerability?
Please note; AMD CPUs are NOT affected by this vulnerability.

The following vendors have responded to this vulnerability with software updates now in progress. Separately Red Hat has completed their updates for Red Hat Linux 5, 6 and 7 (with further applicable updates still in progress).

Other vendors responses are listed below. Thank you:

Amazon Web Services

Apple (currently release notes for an update to macOS to resolve the vulnerability)


Intel’s Security Advisory


Microsoft Windows


Xen Project