Tag Archives: Information Disclosure

Citrix Patches Critical FileShare Vulnerabilities

If you manage a non-cloud version of Citrix ShareFile, please make certain you are using a non-vulnerable version of the ShareFile storage zones Controller. Please refer to the following Citrix security bulletin for the appropriate guidance: https://support.citrix.com/article/CTX269106
Adding to the challenges of current remote working, I wanted to provide awareness that Citrix has released a security bulletin to address 3 critical information disclosure vulnerabilities in their ShareFile content collaboration and file sharing tool:

Why should these vulnerabilities be considered important?
Given the high severity of these vulnerabilities they may allow a threat actor who has not authenticated with the tool to access the contents of the files stored within the tool. The good news is that at this time these vulnerabilities are not yet being exploited.

What versions are affected?
From the Citrix security bulletin:

Customer-managed storage zones created using the following versions of the storage zones controller are affected:

• ShareFile storage zones Controller 5.9.0
• ShareFile storage zones Controller 5.8.0
• ShareFile storage zones Controller 5.7.0
• ShareFile StorageZones Controller 5.6.0
• ShareFile StorageZones Controller 5.5.0
• All earlier versions of ShareFile StorageZones Controller

Please also note that “Storage zones created using a vulnerable version of the storage zones controller are at risk even if the storage zones controller has been subsequently updated”.

How can I protect my organisation’s or my installation of this Citrix tool?
The good news is that Citrix is notifying customers and channel partners with customer-managed storage zone controllers about these security issues.

However, if for any reason they don’t notify your organisation, but you are using this Citrix tool, please apply the storage zone migration tool as soon as possible to the storage zone controllers managing each impacted storage zone by following the guidance within Citrix’s bulletin.

Microsoft security employee Nate Warfield has shared a Shodan (defined) query which may be of assistance if the countries your organisation operates within are vulnerable to these issues.

Dimitri van de Giessen; an ethical hacker and a system engineer has shared a means of checking if your Citrix ShareFile server is vulnerable (please substitute your Citrix ShareFile URL with the template he provides)

Thank you.

My thanks to BleepingComputer for the initial notification of these vulnerabilities and their compilation of useful resources.

RAMBleed: What you need to know

Yesterday; security researchers disclosed a vulnerability relating to how data is accessed after it is stored within computer memory modules eventually leading to partial data disclosure

This is a low severity (CVSS Base Score: 3.8) but notable vulnerability which cannot be exploited remotely. For organisations and customers; no action is required. It is up to software developers to use trusted execution environments (TEE) e.g. AMD SEV, ARM TrustZone or Intel SGX to protect important data or clear such data from memory after use. Some DDR4 modules are not vulnerable to Rowhammer.

How does this attack take place?
An attacker would first need to compromise your system and persuade you to run an application. Due to the physical effects of creating memory modules which are smaller and smaller the space between memory cells used to store data are subject to electrical interference. This can be exploited by an attacker by reading the data from a memory address of interest over and over again which eventually leads to data corruption causes the binary contents (0 or 1) used to store data to change/”flip” from 0 to 1 or vice versa.

This effect has been seen before in an attack dubbed “Rowhammer” in 2014. That attack can be mitigated by the use of memory modules that use ECC (Error Correction Code). However, this new technique RAMBleed cannot be mitigated by ECC (defined).

What must an attacker do to exploit this vulnerability?
An attacker must first map the memory which contains the data they wish to acquire. They can then work to control data each side in memory of the target data. Accessing this data over and over “hammers” the row with the data within it. If the data is 0, it will flip to 1 and if 1 becomes a zero (0). The attacker can then proceed to repeat this for one column down in the memory segment to obtain the next piece of target data. Researchers were able to obtain 3 to 4 bits (either 0 or 1) per second.

Researchers used this technique to obtain a 2048 bit OpenSSH key from the memory of a server. They did so by first using a technique they named “Frame Feng-Shui” that allows them to place the target data within a physical memory frame (area) of their choice in. The speed was 0.3 bits per second with an accuracy of 82%. By only obtaining some of the data and using a variant of the technique documented within the Heninger-Shacham algorithm they succeeded in obtaining the remainder of the key.

How can an organisation or a consumer/end-user defend against this attack?
Encrypted memory achieved by the use of trusted execution environments (TEEs) e.g. AMD Secure Encrypted Virtualization (SEV), ARM TrustZone or Intel Software Guard Extensions (SGX) will mitigate this attack since the attackers will obtain encrypted rather than ready to use/plain text data.

Alternatively; software developers can clear encryption keys or other sensitive data from memory after using it. Intel recommends it’s guidelines for resisting side-channel and timing side channel attackers:

A lesser known mitigation is the use of DDR4 memory modules that should disrupt the success of the Rowhammer attack. The Maximum Activation Count (MAC) of a memory row is not vulnerable to Rowhammer when the MAC has a value of “unlimited”.

This field exists within the SPD (Serial Presence Detect) technique of accessing memory. From the following page, many but not all of the examined DDR4 modules feature this setting. For example, my 4x 16 GB (64GB) Corsair Dominator Platinum PC4-21300 (CMX64GX4M4A2666C15) modules feature this setting and so appear not to be vulnerable to the Rowhammer technique. You can see this from the first attached screenshot (denoted by the value “Unlimited MAC”):

These screenshots were obtained from the RAMMon application available from PassMark.

Thank you.

Responding to the Intel Spoiler Vulnerability

Updated: 20th March 2019
The Intel Spoiler vulnerability is not as bad as predicted. Software developers should continue to use safer code development practices.

After the disclosure earlier this month of this vulnerability Intel have provided further information on how it affects their microprocessors. They have clarified that the Spoiler exploit by itself does not reveal secret data and is not a speculative execution side channel method:

Other good news is that existing mitigations such as KPTI (kernel page table isolation) reduce the risk of leaking data across privilege levels. They again confirmed that side channel safe software development practices such as “ensuring execution time and control flows are identical regardless of secret data” will mitigate classic side channel methods enabled by the Spoiler exploit. Furthermore, they confirmed memory modules which are already mitigated against Rowhammer attacks remain protected against the Spoiler exploit.

Lastly AMD provided formal confirmation that their microprocessors are not vulnerable after preliminary findings suggested they weren’t vulnerable. AMD’s statement is available from this link.

Thank you.

Original Post:
Earlier this month a new vulnerability was disclosed in a research paper titled “Spoiler: Speculative load hazards boost Rowhammer and cache attacks”.

TL DR: Mitigating this newly disclosed vulnerability is the job of software developers to work around using safer code development practices. Mitigating this issue in hardware will take longer since current measures cause too much of a performance penalty.

Why should this vulnerability be considered important?
Using this new method; attackers are likely to find existing cache and memory Rowhammer attacks easier to carry out. In addition, JavaScript (defined) attacks which can take long periods of time may be shortened to mere seconds. The paper contains a cache prime and probe technique to leak sensitive data using JavaScript.

This Spoiler vulnerability can be used by attackers (who MUST have already compromised your system) to extract sensitive information from the systems memory (RAM). An attack does not require elevated privileges.

What CPUs (microprocessors / computer chips) are affected?
This vulnerability affects Intel processors only; first generation Intel Core (from early 2006) and later are affected. ARM and AMD processors are not affected. Any system with an Intel Core processor is affected regardless of the operating they are using namely Linux, Unix, Apple macOS and Windows can be all affected.

How does this vulnerability achieve the above results?
The security researchers who authored the paper found a vulnerability in the memory order buffer that can be used to gradually reveal information about the mappings of physical memory to non-privileged software processes (in other words; applications). This technique also affects virtual machine (VM) and sandboxed (defined) environments.

The technique works by understanding the relationship between virtual and physical memory by timing the speculative load and store operations to these areas while looking out for discrepancies which disclose the memory layout to you. With this information an attacker knows where to focus their efforts.

Intel’s proprietary implementation of the memory subsystem (memory disambiguation) is the root cause of the vulnerability. When a physical address conflict (the address/area is already in use) occurs, the algorithm leaks the access timings. The algorithm in the researcher’s words works as follows “Our algorithm, fills up the store buffer within the processors with addresses that have the same offset but they are in different virtual pages. Then, we issue a memory load that has the same offset similarly but from a different memory page and measure the time of the load. By iterating over a good number of virtual pages, the timing reveals information about the dependency resolution failures in multiple stages.”

How can this vulnerability be mitigated/patched?
This vulnerability lies within the memory disambiguation algorithm which won’t be trivial to resolve anytime soon. Since this vulnerability is not related to last years Spectre vulnerability; mitigations for that vulnerability don’t help here. Current Spoiler mitigations have too much of performance penalty. At this time, Intel has issued the following statement:

“Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe development practices. This includes avoiding control flows that are dependent on the data of interest. We likewise expect that DRAM modules mitigated against Rowhammer style attacks remain protected. Protecting our customers and their data continues to be a critical priority for us and we appreciate the efforts of the security community for their ongoing research.”

The side channel safe development practices are linked to below:

Software Guidance for Security Advisories

Addressing Hardware Vulnerabilities

Thank you.

Vendors Respond to Foreshadow (L1TF) Vulnerabilities

Yesterday, academic and security researchers publically disclosed (defined) 3 new vulnerabilities affecting Intel CPUs (AMD and ARM are not affected).

What are these new vulnerabilities and what can they allow an attacker to do?
The first vulnerability known as Foreshadow or CVE-2018-3615 is used to extract data from an Intel SGX (Software Guard Extensions)(defined) secure enclave (area) by creating a shadow copy of the SGX protected data but that copy does not have the protection of SGX and can be read/accessed by the attacker. The attacker can also re-direct speculative execution into copying further private/sensitive into the shadow copied area while at the same time making it appear that area is genuine and thus has the same protection as the real SGX protected data.

The second vulnerability (part of a wider Foreshadow Next Generation (NG) group of two variants) known as CVE-2018-3620 allows the reading of data copied into the level 1 cache (defined) of a CPU (defined) when that data is in use by a computer operating system e.g. Red Hat Linux, Apple macOS or Microsoft Windows.

The third vulnerability is the second and final variant of the Foreshadow NG group known as CVE-2018-3646.  This affects virtualised environments. If a CPU thread (defined) being directed by an attacker is able to read the level 1 cache of a CPU that is also shared by another thread by a victim user (within another virtualised environment but using the same physical CPU) while that request will be blocked; if the information the attacker is looking to steal is in the level 1 cache they may still get a glimpse of this information.

How can I protect myself from these new vulnerabilities?
For the first and second vulnerabilities; the microcode (defined)/firmware (defined) updates made available earlier this year coupled with the newly released updates for operating systems linked to below will mitigate these two issues.


For the third vulnerability; affecting virtualised (defined) environments there are operating system updates and microcode/firmware updates available that will occasionally clear the contents of the level 1 cache meaning that when the attacker attempts to read it they will not receive any benefit from doing so. Partially removing the usefulness of the cache will have a performance impact from a few percent up to 15 percent in the worst case scenario.

However to completely mitigate this third vulnerability a capability known as Core Scheduling needs to be leveraged. This ensures that only trusted/non attacker controlled virtual machines have access to the same thread (this capability is already available in some virtual machine (hypervisor)(defined) environments).

However in some environments if it cannot be guaranteed that all virtual machines are trustworthy the disabling of Intel Hyper Threading (this means that only 1 thread will work per CPU core)(otherwise known as simultaneous multi-threading (SMT)(defined)) may be necessary and will more significantly impact performance than just the level 1 cache clearing.

In summary for this third vulnerability; depending upon the virtualised environment you are using and the trustworthiness of the virtual machines you are using will determine how many of the these extra security measure you will need to take.

To be clear I am NOT advocating that Intel Hyper Threading/SMT be disabled EN MASSE for security reasons. As per the advice in the linked to advisories (below)(specifically Intel and VMware) ; you MAY wish to disable Intel Hyper Threading/SMT to mitigate the third vulnerability (CVE-2018-3646) depending upon the environment your virtualised machines are operating.

This Ars Technica article explains it very well: “if two virtual machines share a physical core, then the virtual machine using one logical core can potentially spy on the virtual machine using the other logical core. One option here is to disable hyperthreading on virtual-machine hosts. The other alternative is to ensure that virtual machines are bound to physical cores such that they don’t share.”


Please find below links to vendor responses on these vulnerabilities as well as videos that can help in understanding these vulnerabilities:

Thank you.


Foreshadow Vulnerability Official Website:

Intel’s Blog Post:

Intel’s FAQ Page:

Intel’s Security Advisory:

Intel’s Software Developer Guidance:

Red Hat’s Security Advisory:

Linux Kernel Patch:

Oracle’s Security Advisory:

Amazon Web Services’ Security Advisory:

Google Cloud Security’s Blog Post:

Microsoft Windows Azure’s Guidance:

Microsoft’s Windows Security Advisory (high level details):

Microsoft’s Technical Analysis of the Foreshadow Vulnerabilities:

VMware Security Advisories:


Foreshadow Video (explains the first vulnerability very well):

Intel’s Video (explains all 3 vulnerabilities):

Demonstration of the Foreshadow attack:

Red Hat’s Video (explains all 3 vulnerabilities):

Red Hat’s In-depth video of the 3 vulnerabilities:


SpectreRSB and NetSpectre Vulnerabilities Explained

In late July; security researchers publicly disclosed (defined) a new set of vulnerabilities within Intel CPUs (defined) (and possibly AMD and ARM; which the researchers also notified). These vulnerabilities are collectively referred to as SpectreRSB (Return Stack Buffer). The purpose of an RSB is explained in this document (PDF) but in summary it is a buffer (defined) that stores multiple return addresses while attempting to predict function (a set of instructions that carries out a specific action within a program) return addresses.

A very short time later nearing the end of July; a separate set of researchers released details of another vulnerability known as NetSpectre. This is an evict and reload cache attack that targets systems remotely to extract data.

How could an attacker exploit these vulnerabilities and what is the result?
For SpectreRSB; an attacker could recover data from the speculative execution feature of the CPU by targeting the Return Stack Buffer and predicting the return address which it stores. By manipulating the data it contains by predicting the return address the CPU will access when it completes a task the attacker can influence the address CPU will jump to and thus jump to an address of the attacker’s choosing. Unfortunately; this buffer is shared among the threads (defined) on the same virtual process thus affecting multiple running processes and virtual machines.

The attacker could alter the RSB to expose and gather data from applications running within the CPU. Another form of manipulation by the researchers resulted in them being able to expose data contained within Intel’s Software Guard Extensions (defined)(PDF).


Separately for the NetSpectre vulnerability; if attackers can send specifically crafted packets (defined) to a vulnerable system they can use the responses they receive to infer data from that systems memory. Currently this can only take place at a very low rate; 15 bits per hour. This means 15 times a zero or a one; in other words true or false (I’m not referring to Boolean logic here; just trying to convey a concept) or even simpler on for 1 and off for zero. This increased to 60 bits per hour for an Intel CPU equipped with AVX2 instructions.

With such a low throughput at this time (although I realise an attack can usually be refined and significantly improved within a short time); this attack is not a practical threat but more a theoretical weakness.

How can I protect myself from these vulnerabilities?
The good news for this SpectreRSB subclass of vulnerabilities is that Intel has already created an update but not for all of it’s CPU (Intel Core i7 Skylake (6th Generation Core models) and later CPUs). The researchers are aware of this patch and are recommending it’s use. When I use the word subclass above; my meaning is that SpectreRSB is a subclass of the original Spectre vulnerabilities from January this year. Red Hat also announced they are reviewing these vulnerabilities.

Intel however have stated that existing mitigations from the vulnerabilities disclosed in January will protect against this new subclass. However this is unconfirmed at this time.


While an APT (defined) could leverage the NetSpectre vulnerability over a period of weeks or months to extract useful data; existing mitigations for Spectre variant 1 and variant 2 mitigate this new vulnerability reinforcing my statement above of being a theoretical weakness.

In summary; to protect against both classes of these vulnerabilities; please continue to roll-out the mitigations for the Spectre vulnerabilities from January 2018 (if you have not already completed them).

For any system which cannot be updated (due to performance or end of life constraints e.g. Intel not providing updates for some CPUs); seek to migrate the responsibilities/roles/duties of these systems to newer CPUs which have received updates. A list of patched and un-patched Intel CPUs is available here (PDF).

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

Cloudflare addresses data leak

For 5 days within February this year; an information disclosure issue affected Cloudflare’s infrastructure. This led to their systems inadvertently leaking private session keys, website cookies, encryption keys and passwords.

Why should this vulnerability be considered important?

The scale of the issue was large, affecting an estimated 2 million websites. This flaw was due to a coding error within a parser (defined) (undetected at the time) used to modify HTML webpages and related to how the memory containing buffers (defined) of their NGINX (defined) web server functioned. Google Project Zero vulnerability researcher Tavis Ormandy contacted Cloudflare over Twitter who mitigated the issue in 47 minutes and completed their work in less than 7 hours; an incredibly swift resolution. Cloudflare later noted it would usually take 3 months to resolve an issue similar to this.

How can I protect myself from this vulnerability?

Cloudflare documented their findings of this incident within this blog post. Their analysis shows no evidence of attackers using the leaked information for malicious account access, accessing sensitive information or fraudulent purchases (in the case of exposed credit card numbers).

Cloudflare is continuing to review the leaked information and working to remove it from third party caches. They have committed to a review (both internal and with the assistance of external auditor Veracode) of the parser code which inadvertently lead to this information leakage.

As a precaution I would recommend monitoring any affected accounts for unwanted activity and change passwords and enable 2 factor authentication should any unwanted activity take place. The list of affected websites is here.

Further discussion of the impact of this issue is available from this SANS forum post and this Softpedia news article.

Thank you.