TechRepublic

Account information.

specter attack

Share with Your Friends

Spectre and Meltdown explained: A comprehensive guide for professionals

Your email has been sent

Image of James Sanders

In January 2018, the Spectre and Meltdown security vulnerabilities were publicly disclosed , prompting widespread concern among security professionals as the duo can be used to steal data from nearly any computer, as well as iPhones and iPads and other mobile devices.

Spectre and Meltdown individually represent classes of hardware vulnerabilities, each with a number of variants dependent on specific silicon-level functionality. Differences between manufacturers (e.g., Intel vs. AMD) and architectures (e.g., x86-64 vs. Arm) make some processors vulnerable to more variants than others. While these are fundamentally hardware design flaws, attempts to remediate on a software level have seen some success.

Understanding of Spectre and Meltdown has increased significantly since the initial disclosure, and security researchers continue to study these vulnerabilities. Presently, 13 Spectre variants and 14 Meltdown variants have been identified. Initially, AMD processors were thought to be immune to Meltdown, though one variant has been successfully demonstrated on AMD systems.

TechRepublic’s cheat sheet for Spectre and Meltdown is as a comprehensive guide to understanding how the vulnerabilities work, as well as a resource for the most up-to-date patching and mitigation information.

SEE: All of TechRepublic’s cheat sheets and smart person’s guides

Note: TechRepublic’s cheat sheet to Spectre and Meltdown utilizes the stratification of variants, definitions, and explanations from “ A Systematic Evaluation of Transient Execution Attacks and Defenses ,” by Claudio Canella, Daniel Gruss, Moritz Lipp, Philipp Ortner, Michael Schwarz, and Benjamin von Berg of Graz University of Technology; Frank Piessens and Jo Van Bulck of KU Leuven; and Dmitry Evtyushkin of The College of William and Mary. That document serves as further analysis of the original papers in which Meltdown and Spectre were presented.

What are Spectre and Meltdown?

In the most basic definition, Spectre is a vulnerability allowing for arbitrary locations in the allocated memory of a program to be read. Meltdown is a vulnerability allowing a process to read all memory in a given system. Spectre and Meltdown are not singular flaws–they individually represent a class of closely-related variants.

Spectre and Meltdown are uniquely dangerous security vulnerabilities that allow malicious actors to bypass system security protections present in nearly every recent device with a CPU-not just PCs, servers, and smartphones, but also Internet of Things (IoT) devices like routers and smart TVs. By leveraging the duo, it is possible to read protected system memory, gaining access to passwords, encryption keys, and other sensitive information.

Spectre and Meltdown are representative examples of “transient execution” attacks, which rely on hardware design flaws in the implementation of speculative execution, instruction pipelining, and out-of-order execution in modern CPUs. While this trio are essential to performance optimizations inherent to modern processors, implementations of these vary between CPU manufacturers and microarchitectures; as a result, not all Spectre and Meltdown variants are exploitable on all microarchitectures.

Following the disclosure of Spectre and Meltdown, further research into CPU side-channel flaws yielded a new vulnerability class, “ Microarchitectural Data Sampling ” (MDS), which exploits CPU-internal buffers rather than CPU caches. This target makes attacks that leverage MDS more difficult to mitigate, though are also more difficult for hackers to usefully exploit.

Various factors have immeasurably complicated the understanding of Spectre and Meltdown, including:

  • Technical differences in variances discovered after the initial disclosure
  • The differing extent to which microarchitecture types are susceptible to transient execution attacks
  • The difficulty of and differing ways in which Spectre and Meltdown risks can be mitigated
  • The financial hit feared by processor manufacturers and hardware vendors
  • Politics endemic to the IT industry
  • Widely disseminated misinformation days before and immediately following initial disclosure

TechRepublic’s cheat sheet cites and contextualizes-or, as necessary, corrects-claims regarding Spectre and Meltdown that are incongruent with real-world circumstances regarding the duo.

Additional resources

  • Major Intel, Arm chip security flaw puts your PCs, phones at risk (CNET)
  • Congress: Please tell US about security vulnerabilities sooner (CNET)

What risks are associated with Spectre and Meltdown?

Spectre and Meltdown enable attackers to extract encryption keys and passwords from compromised systems, enabling other attacks dependent on access to compromised systems. Leveraging Spectre and Meltdown does not require a user to run a particular maliciously-formed executable, as JavaScript-based proofs-of-concept demonstrate the potential of exploiting these vulnerabilities inside a web browser. (In response, browser vendors have reduced the precision of high-resolution timers needed to successfully carry out an attack.)

For cloud computing, Spectre and Meltdown can be leveraged by attackers to escape software containers, paravirtualized systems, and virtual machines.

As a standalone vulnerability, Spectre and Meltdown are fairly inefficient for mass data exfiltration, as initial research demonstrates Meltdown is able to access data at about 120 KB/s, with Spectre around 1.5 to 2 KB/s. Further, Spectre-BTB (Variant 2) requires 10-30 minutes for initialization on a system with 64 GB RAM, which is anticipated to scale “roughly linearly” with increases in host RAM size.

SEE: Cybersecurity strategy research: Common tactics, issues with implementation, and effectiveness (Tech Pro Research)

Exploitation of Spectre and Meltdown can be performed untraceably–that is, without leaving evidence of an exploit in system logs. This makes the pair difficult to detect in targeted malware attacks, though known malware signatures are still possible to determine by traditional means.

  • Meltdown-Spectre: Malware is already being tested by attackers (ZDNet)
  • Class-action suits over Intel Spectre, Meltdown flaws surge (CNET)

How do Spectre and Meltdown work?

The mechanics of Spectre and Meltdown require an understanding of how the microarchitecture of modern processors are designed.

A quick primer on modern processor design

Improvements in performance in modern processors are derived from a number of techniques. Limitations in augmenting the physical attributes of processors ( shrinking transistor size and increasing clock frequencies) require architectural changes to how processors work in order to deliver higher-performing parts. These changes focus largely on parallelism: Optimizing and lengthening instruction pipelines , allowing multiple operations to be performed in parallel in a logical core (thread), and increasing the number of logical and physical cores on a processor.

Other properties in modern processors include virtual (paged) memory , a method that streamlines memory management across processes, privilege levels , which allow operating systems to control which areas of virtual memory can be read by other processes, and CPU cache , in which data in system RAM is cached in order to reduce latency.

Two independent optimization techniques of modern processors, used in conjunction, are key to understanding how Spectre and Meltdown are hardware-level vulnerabilities.

Out-of-order execution allows for the simultaneous use of all the execution units in a CPU core. As explained in the Meltdown paper , “Instead of processing instructions strictly in the sequential program order, the CPU executes them as soon as all required resources are available. While the execution unit of the current operation is occupied, other execution units can run ahead. Hence, instructions can be run in parallel as long as their results follow the architectural definition.”

The state of instructions processed out of order are stored in a re-order buffer, from which they are committed in order.

Speculative execution allows processors to speculate on future instruction directions and proactively execute instructions along these paths before knowing if the instructions are correct. An example in the Spectre paper , “Consider an example where the program’s control flow depends on an uncached value located in external physical memory. As this memory is much slower than the CPU, it often takes several hundred clock cycles before the value becomes known. Rather than wasting these cycles by idling, the CPU attempts to guess the direction of control flow, saves a checkpoint of its register state, and proceeds to speculatively execute the program on the guessed path.”

When the value arrives from memory, the correctness of the guess is checked. If correct, the results are committed, “yielding a significant performance gain as useful work was accomplished during the delay.” If wrong, the speculative execution is discarded. Performance wise, this is transparent-the speeds are comparable to idling, as if the speculative execution never occurred. Importantly, it is possible to speculatively execute instructions on both in-order and out-of-order pipelines.

In terms of security, speculative execution requires executing a program in potentially incorrect ways. To maintain functional correctness, these incorrectly speculated, or transient executions, are intended to not be exposed to the program. They are not committed, and are flushed from the execution pipeline, reverting architectural effects the instructions may have had.

However, according to the Systematic Evaluation paper , “While the architectural effects and results of transient instructions are discarded, microarchitectural side effects remain beyond the transient execution. This is the foundation of Spectre, Meltdown, and Foreshadow. These attacks exploit transient execution and encode secrets in the microarchitectural side effects (e.g., cache state) to transmit them (to the architectural level) to an attacker.”

How Spectre works

Spectre, according to the original authors of the Spectre paper , “[induces] a victim to speculatively perform operations that would not occur during strictly serialized in-order processing of the program’s instructions, and which leak victim’s confidential information via a covert channel to the adversary.”

Spectre attacks are conducted in three steps:

  • The setup phase, in which the processor is mistrained to make “an exploitably erroneous speculative prediction.”
  • The processor speculatively executes instructions from the target context into a microarchitectural covert channel.
  • The sensitive data is recovered. This can be done by timing access to memory addresses in the CPU cache.

How Meltdown works

Meltdown exploits a race condition between memory access and privilege level checking while an instruction is being processed. In conjunction with a CPU cache side-channel attack, privilege level checks can be bypassed, allowing access to memory used by an operating system, or other running processes. In certain circumstances, this can be used to read memory in paravirtualized software containers.

Meltdown attacks, according to the original authors of the Meltdown paper , are conducted in three steps:

The content of an attacker-chosen memory location, which is inaccessible to the attacker, is loaded into a register. A transient instruction accesses a cache line based on the secret content of the register. The attacker uses Flush+Reload to determine the accessed cache line and hence the secret stored at the chosen memory location.

Understanding the difference between Spectre and Meltdown

Despite the simultaneous publication of Spectre and Meltdown, the two exploit different properties of CPUs; the only commonality between Spectre and Meltdown is the utilization of transient execution.

Spectre relies on misprediction events to prompt transient instructions. Spectre works only with data accessible architecturally to an application. To contrast, Meltdown relies on transient out of order instructions following an exception. Meltdown relies on transient instructions inaccessible architecturally to an application.

  • Beyond Spectre: Foreshadow, a new Intel security problem (ZDNet)
  • All Intel chips open to new Spoiler non-Spectre attack: Don’t expect a quick fix (ZDNet)

How many variants of Spectre and Meltdown exist?

In the Systematic Evaluation paper , researchers created a tree illustrating potential variants, defining 13 exploitable variants of Spectre and 14 variants of Meltdown (of which, 6 of the 14 are not exploitable).

Variants of Spectre

This new classification of Spectre groups attacks by the microarchitectural element they exploit. This creates four primary attack types: Spectre-PHT, exploiting the Pattern History Table; Spectre-BTB, exploiting the Branch Target Buffer; Spectre-RSB, exploiting the Return Stack Buffer; and Spectre-STL, exploiting the CPUs memory disambiguation prediction (specifically, store-to-load forwarding).

The first three attack types rely on mistraining the branch predictor, which can occur in one of four ways, according to researchers:

Within the same address space and the same branch location that is later exploited (same-address-space in-place mistraining) Within the same address space with a different branch (same-address-space out-of-place) Within an attacker-controlled address space with a branch at the same address as the victim branch (cross-address-space in-place) Within an attacker-controlled address space at a congruent address to the victim branch (cross-address-space out-of-place)

Spectre-PHT (Bounds Check Bypass)

Spectre-PHT encompasses Variant 1 (CVE-2017-5753) and Variant 1.1 (CVE-2018-3693), as well as NetSpectre .

Spectre-PHT has been demonstrated as possible in all four mistraining types (PHT-CA-IP, PHT-CA-OP, PHT-SA-IP, and PHT-SA-OP) on Intel, Arm, and AMD (Zen microarchitecture) processors.

Spectre-BTB (Branch Target Injection)

Spectre-BTB is Variant 2 (CVE-2017-5715).

In the Systematic Evaluation , Researchers have demonstrated it as possible in all four mistraining types (BTB-CA-IP, BTB-CA-OP, BTB-SA-IP, and BTB-SA-OP) on Intel, but out of place mistraining has not been demonstrated on AMD (Zen microarchitecture) or Arm, indicating they “assume that they are possible, but that they require a different set of bits that we were not able to determine.”

Spectre-RSB (Return Stack Buffer Mispredict)

Two groups of researchers have demonstrated Spectre-type vulnerabilities utilizing the Return Stack Buffer. These are published SpectreRSB and ret2spec , the latter of which notably has been demonstrated with JIT-compiled code in web browsers.

Spectre-RSB has been demonstrated in all four mistraining types (RSB-CA-IP, RSB-CA-OP, RSB-SA-IP, and RSB-SA-OP) on Intel and AMD (Zen microarchitecture). Arm claims that same-address-space mistraining is possible, but makes no mention of cross-address-space. The researchers indicate that “while we expect them to work, we were not able to observe any leakage with any of our proofs of-concept,” adding that “We assume that it is a timing issue.”

Spectre-STL (Speculative Store Bypass)

Spectre-STL, previously Variant 4 (CVE-2018-3639), was first disclosed in May 2018. It has been demonstrated on Intel, AMD, and Arm.

This is acutely different from other Spectre variants. It exploits store-to-load forwarding, which does not involve history-based prediction; because of this, mistraining (the first step) is not possible. As a result, Spectre-STL can only access memory in the same privilege level.

Variants of Meltdown

The new classification of Meltdown variants contains two levels. The first level categorizes attacks by the exception causing a transient execution. For page faults, these are subclassified by the page-table entry protection bits.

Table Data: Canella et al.

Further, for ease of understanding, Meltdown variants are classified by the type of data recoverable, and the ability to cross privilege levels.

Meltdown variants have been observed to rely solely on faults. Analysis of aborts and interrupts indicate that those functions provide no transient execution to exploit by Meltdown.

Meltdown-US (Supervisor-only Bypass)

Meltdown-US, previously Variant 3 (CVE-2017-5754), was the first Meltdown variant disclosed. Most processors include “user” and “supervisor” page-table attributes to designate ownership of virtual memory pages; Meltdown-US demonstrates the ability to read kernel memory from user space on pipelined processors that fail to transiently enforce these flags.

Refinements to Meltdown-US utilizing transactional synchronization extensions enable attackers to increase data access speed. Further, Meltdown-US is capable of extracting uncached data from memory.

Researchers successfully demonstrated Meltdown-US on Intel and Arm Cortex-A75.

Meltdown-P (Virtual Translation Bypass)

Meltdown-P, also known as Foreshadow (CVE-2018-3615), leverages flaws in Intel SGX (Software Guard Extensions). Meltdown-P forces a page fault to occur during unauthorized access to page-table memory, providing an exploitable path to reading protected memory.

When researchers disclosed Foreshadow to Intel, the company identified variants called Foreshadow-NG (CVE-2018-3620 and CVE-2018-3646) that allow attackers to read any data stored in L1 cache, including System Management Mode, host OS kernel, and hypervisor data. These variants can allow attackers on cloud platforms to read information from other virtual machines on the same physical hardware.

Researchers successfully demonstrated Meltdown-P is demonstrated on Intel processors. Intel’s documentation refers to Meltdown-P as L1 Terminal Fault (L1TF).

Meltdown-GP (System Register Bypass)

Meltdown-GP, also known as Variant 3a (CVE-2018-3640), allows attackers to read privileged system registers.

Researchers successfully demonstrated Meltdown-GP on Intel and Arm Cortex-A15, A57, and A72.

Meltdown-NM (FPU Register Bypass)

Meltdown-NM, also known as LazyFP (CVE-2018-3665), exploits speculative execution used in conjunction with context switching of the floating-point unit. Researchers demonstrated the ability to retrieve AES-NI keys.

Researchers successfully demonstrated Meltdown-NM on Intel processors.

Meltdown-RW (Read-only Bypass)

Relative to the above four attacks, Meltdown-RW is the first to bypass “page-table based access rights within the current privilege level,” according to the Systematic Evaluation . Further, Meltdown-RW demonstrates that “transient execution does not respect the ‘read/write’ page-table attribute. The ability to transiently overwrite read-only data within the current privilege level can bypass software-based sandboxes which rely on hardware enforcement of read-only memory.”

Meltdown-RW was initially erroneously labeled “Spectre Variant 1.2,” though because the cause of transient execution is a page-fault exception, the correct classification of this vulnerability is Meltdown.

Researchers successfully demonstrated Meltdown-RW on Intel and Arm processors.

Meltdown-PK (Protection Key Bypass)

Meltdown-PK exploits “Memory Protection Keys for Userspace” (PKU or PKEYs) first introduced in Intel’s Skylake-based Xeon CPUs. This variant bypasses read and write isolation for PKU within the containing process. According to the Systematic Evaluation , in which this variant was introduced, “in contrast to cross-privilege level Meltdown attack variants, there is no software workaround. Intel can only fix Meltdown-PK in new hardware or possibly via a microcode update,” though the functionality is only exposed in Linux if the kernel was configured and built with support enabled.

Meltdown-PK is exploitable only on Intel CPUs featuring PKU support.

Meltdown-BR (Bounds Check Bypass)

Meltdown-BR exploits the bound-range exceeded exception present in x86 processors. The variant can be used to capture out-of-bounds data safeguarded by the IA32 “bound” opcode on Intel or AMD, or MPX on Intel.

Researchers successfully demonstrated Meltdown-BR on Intel Skylake i5-6200U and AMD Ryzen ThreadRipper 1920X CPUs. This is the first, and presently only, Meltdown variant exploitable on AMD. No equivalent to “bound” exists on Arm .

Faults unexploitable by Meltdown

In Intel, AMD, and Arm systems, other possible faults indicated in the graph of variants do not produce scenarios exploitable by Meltdown. These include division errors (Meltdown-DE), supervisor access (Meltdown-SM), alignment faults (Meltdown-AC), segmentation faults (Meltdown-SS), and instruction fetch (Meltdown-XD and Meltdown-UD).

  • SpectreRSB: New attack targets CPU return stack buffers (ZDNet)
  • AMD on chip flaws: ‘Newly outed bugs are real but no big deal, and fixes are coming’ (ZDNet)

What products are affected by Spectre and Meltdown?

Spectre and Meltdown are wide-ranging hardware flaws that affect the vast majority of devices currently available for sale, devices currently deployed, and legacy devices dating back to the 1990s, though significant exceptions exist. Because Spectre and Meltdown individually represent a class of flaws-not a single vulnerability-the differences in microarchitecture design in different types of processors impact the extent to which processors are affected.

SEE: 10 dangerous app vulnerabilities to watch out for (free PDF) (TechRepublic)

For individual products and operating systems, the Spectre and Meltdown website maintains a comprehensive list of up-to-date guidance from vendors , including Microsoft, Amazon, and Google, as well as hardware manufacturers such as Apple, Dell, HP, and Lenovo.

In terms of the CPUs that power computers, smartphones, and other devices, products using Intel, AMD, Arm, or POWER CPUs have been demonstrated to be affected by both Spectre and Meltdown; however, not all products using those CPUs are vulnerable. Despite early media reports that “most CPUs released since 1995” are vulnerable, there is-frustratingly-no quick heuristic to determine if a CPU is vulnerable. To gain a better understanding of what is affected by Spectre and Meltdown, an explanation of microarchitecture is necessary.

The claim “most CPUs released since 1995” is a reference to Intel’s P6 microarchitecture , which was introduced with the Pentium Pro in November 1995. P6 was the first Intel processor to use speculative execution and out-of-order processing. This design was used for Pentium 2 and 3 (and Celeron and Xeon variants), and refined versions were used in Pentium M (and Celeron variant) and the first Intel Core Solo and Duo CPUs. P6-based products are unsupported by Intel, and are vulnerable to Spectre and Meltdown.

Intel’s NetBurst microarchitecture was introduced on the Pentium 4 in 2000, as the intended successor to P6. For a variety of reasons-including a 31-stage pipeline that proved to be more of an encumbrance than a benefit-NetBurst was unsuccessful and discontinued by 2008. NetBurst-based products are unsupported by Intel. No data is available to demonstrate that these products are vulnerable to Spectre or Meltdown, but should be considered vulnerable.

Intel Core and succeeding generations of that microarchitecture, including Nehalem, Sandy Bridge, Haswell, and Skylake, trace their lineage from P6, and are affected, as are the low-power Silvermont and Goldmont microarchitectures. Together, these microarchitectures comprise effectively every Intel Core and Intel Xeon processor since 2006, and Intel Atom processors since 2013, the full list of which is provided by Intel .

Conversely, the Itanium microarchitecture (IA-64) is not affected by Spectre and Meltdown, which is explicitly parallel, in-order, requiring the compiler to define what can be done in parallel . Without speculative execution, Spectre and Meltdown are not usable. Likewise, the Bonnell microarchitecture lacks speculative execution capabilities in the interest of power savings, making first-generation Atom processors immune.

AMD microarchitectures starting from K8 (Hammer) through Zen+ are vulnerable to Spectre. The K8 microarchitecture debuted in September 2003 with the Athlon 64, the first of AMD’s CPUs capable of running 64-bit Windows.

In contrast to Intel, AMD CPUs are not vulnerable to Spectre-BTB-SA-OP or Spectre-BTB-CA-OP.

Early reports indicated AMD CPUs are not vulnerable to Meltdown. AMD CPUs are vulnerable to the Meltdown-BR variant, publicly disclosed in November 2018.

SoCs such as the Qualcomm Snapdragon, Apple A-Series, MediaTek Helio, and NVIDIA Tegra, as well as SoCs from other companies including Broadcom, and server processors including Cavium ThunderX, Qualcomm Centriq, and Amazon (AWS) Graviton, utilize Arm microarchitectures.

According to Arm , only the Cortex-R7, R8, A8, A9, A12, A15, A57, A72, A73, A75, and A76 are affected by any variant of Spectre or Meltdown. These designs are used in SoCs by the aforementioned vendors; the designs are used in smartphones, tablets, and other devices.

Notably, the Raspberry Pi series of single-board computers use ARM1176, Cortex-A7, and A53 designs. These designs lack speculative execution capabilities, making them immune to Spectre and Meltdown .

IBM POWER9, POWER8, POWER7+, and POWER7 CPUs are partially vulnerable to Spectre and Meltdown , and have been patched by IBM. POWER4, 5, and 6 family CPUs are likewise partially vulnerable, though will not be patched, as those products have reached end of life.

  • Meltdown-Spectre: IBM preps firmware and OS fixes for vulnerable Power CPUs (ZDNet)
  • Meltdown-Spectre: Oracle’s critical patch update offers fixes against CPU attacks (ZDNet)
  • Intel: We now won’t ever patch Spectre variant 2 flaw in these chips (ZDNet)
  • Spectre and Meltdown: Linux creator Linus Torvalds criticises Intel’s ‘garbage’ patches (ZDNet)

How can I protect against Spectre and Meltdown?

Because of the nature of Spectre and Meltdown, ensuring the latest available patches for your system are installed is necessary. Troublingly, initial patches for Spectre and Meltdown focused on preventing exploitation of a specific methodology, not addressing the microarchitectural vulnerability enabling those attacks.

As of November 2018, on systems with the latest available patches, exploitation of some Spectre and Meltdown variants remained possible under specific circumstances.

Patches for Spectre and Meltdown should be considered a work in progress, with initial patching strategies introduced and rolled back due to instability or findings indicating they were ineffective against specific variants. It is unclear if the pair of vulnerabilities can be completely patched through microcode and software updates, though this uncertainty should not discourage users or administrators from deploying available patches. (This is elaborated on in the following section.)

Servers, desktops, and notebooks

Mitigations for Spectre and Meltdown are delivered through BIOS and OS updates. For BIOS updates, check with your manufacturer to determine if BIOS updates are available. When applying BIOS updates, follow the instructions exactly as provided by your system manufacturer to prevent inadvertently causing damage to your computer.

Generally speaking, OS updates are delivered automatically through Windows Update, the App Store (on Mac OS), or through the package manager on Linux systems. Updates will not be made available for an OS that has reached end of life, such as Windows XP.

iOS and Android devices

For users of Apple devices, including iPhone, iPad, and Apple TV devices, software and firmware updates have been issued to address Spectre and Meltdown.

For Android users, the first round of patches were delivered in the 2018-01-05 security patch level. Though this is not specific to Spectre and Meltdown, ensure that Android devices are updated to a minimum of 7.0 (Nougat), as prior versions are unsupported.

Cloud computing services

Generally, users of cloud computing services are reliant on the platform provider to update the underlying infrastructure. Users of cloud-powered virtual machines may need to update their VMs, though this may not be specific to Spectre and Meltdown.

  • How to tell if your Linux machine is patched against Meltdown and Spectre (TechRepublic)
  • Microsoft delivers free Meltdown-Spectre assessment tool for IT pros (ZDNet)
  • Apple releases iOS update to patch Spectre chip flaw (CNET)
  • How to protect Windows Server from Meltdown and Spectre (ZDNet)

How will installing patches to protect against Spectre and Meltdown affect my computer?

The creation, deployment, and performance of mitigations to Spectre and Meltdown are subject to political in-fighting proportional to the severity of the vulnerabilities. Early software patches for the duo were rife with optimization problems, leading to performance regressions for a variety of reasons, including patches being applied to systems not vulnerable to specific variants, patches to microcode and operating system kernels conflicting with each other, and poor testing prior to deployment leading to system instability, particularly on Windows.

A quick history lesson about Spectre and Meltdown

Disclosure of Spectre and Meltdown to affected vendors occurred on June 1, 2017, providing six months to develop mitigations for Spectre and Meltdown. While this nominally happened behind closed doors, the open-source nature of Linux and BSD led to pull requests for mitigations being submitted partially publicly.

Days before the public announcement of Spectre and Meltdown, patches had become publicly available and tested by developers on custom-built kernels. These patches were benchmarked, resulting in reports of “up to 30% performance regression” being bandied about in developer circles and technology news websites.

Taken generously, these benchmarks were “worst-case scenario.” Less generously, the way in which the kernels were built were simply faulty, as they omitted a component of the patches as actually shipped in production kernels from Debian, Ubuntu, Red Hat, and other Linux distributions.

Spectre relies on the exploitation of processor components that enable speculative execution. Eliminating this risk by disabling these components is a technically possible-but not practically useful-idea, as the performance degradation would be far too high. This strategy is not being seriously considered as a real-world solution to the problem.

One of the first Meltdown patches, Kernel Page Table Isolation (KPTI), was developed originally as KASLR prior to the discovery of Meltdown. KPTI addresses Meltdown by separating user-space and kernel-space page tables. System calls or interrupts have context switching overheads, incurring a performance penalty of 7-17%; using process-context identifiers (PCIDs) reduces that overhead. KPTI was been backported to kernel 4.4 and 4.9, but support for PCIDs had not been. A lateral kernel upgrade adding KPTI to those kernels indicates regressions, upgrading to the (then-latest) 4.14 with KPTI and PCIDs enabled showed performance increases in use cases with frequent context switching , such as PostgreSQL and Redis.

Initial patches causing system instability

Initial patches for Windows created system instability, with Microsoft’s initial patch being blacklisted on systems with third-party antivirus software , as the patch caused Blue Screen of Death incidents on these systems. Microsoft subsequently halted all updates to systems with incompatible third-party antivirus software. Microsoft’s Meltdown patch caused certain AMD systems running Windows 10 to boot loop, unfortunate both for the fact that AMD systems are not vulnerable to those variants of Meltdown, and Windows 10 Home users have no easy way of deferring updates, prompting Microsoft to withdraw the patch .

Intel’s first microcode update caused random reboots, first thought to affect only Haswell and Broadwell CPUs, and later confirmed to affect Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake CPUs. The issue became sufficiently widespread that Intel directed manufacturers to stop rolling out microcode updates until a new update could be issued.

Unsuccessful attempts by Microsoft to patch Windows 7 and Server 2008 R2 led to an incident called ” Total Meltdown ,” making the vulnerability dramatically worse. The patch incorrectly set permissions, causing memory that should only be accessible to the kernel to be automatically mapped for every process running at user-level privileges; this allowed malicious programs to read complete system memory at speeds of gigabytes per second, instead of 120 KB/s which Meltdown is otherwise capable of.

In April 2018, it was discovered that patches in Windows 10 for Spectre and Meltdown prior to the April 2018 update were completely useless, as a program could access the entire kernel page table by calling NtCallEnclave. (The April 2018 Windows 10 Update caused a variety of other problems .)

Practical performance implications of patching

Microsoft’s original guidance on performance degradation noted that Spectre-PHT and Meltdown-US had minimal performance impact, though patching Spectre-BTB caused performance regressions. From the January 2018 post by Terry Myerson:

With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds. With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance. With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance. Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.

These regressions are expected to be minimized in Windows 10 19H1, as Microsoft is planning to adopt Google’s Retpoline method to patch Spectre-BTB.

For Linux, performance impact is heavily configuration dependent. Performance regressions are likely to be more noticeable on older LTS kernels, particularly 4.4 and 4.9, though 4.14 or 4.19 are preferable. Regressions on desktop usage is negligible, though system calls or interrupts continue to incur context switching overheads, most visibly on database applications. This is reduced to margin-of-error territory by use of Retpoline on existing hardware.

A new mitigation, Single Thread Indirect Branch Predictors (STIBP), was introduced in kernel 4.20 for systems with up-to-date microcode, though has significant performance regressions associated with it. STIBP is unlikely to remain enabled, at least in the current state. The fix is intended to address Spectre-BTB across threads, though the PortSmash vulnerability announced in November 2018 is prompting users to disable symmetric multithreading (SMT) entirely, negating the need for that patch.

  • Windows 10 alert: All versions get new Intel patches for Spectre, Foreshadow bugs (ZDNet)
  • Meltdown and Spectre response hampered by ‘exclusive club’ secrecy (ZDNet)
  • Windows Meltdown-Spectre: Watch out for fake patches that spread malware (ZDNet)
  • Check if your Chromebook is protected against the Meltdown vulnerability (CNET)

Will buying a new processor help protect against Spectre and Meltdown?

New processors do address the Spectre and Meltdown vulnerabilities at a hardware level, though buying a new processor for that reason alone is probably unwarranted. Patches presently available and immediately on the horizon reduce performance penalties for security to background noise.

SEE: Special report: A winning strategy for cybersecurity (free PDF) (TechRepublic)

However, as of November 2018, on systems with the latest available patches, exploitation of some Spectre and Meltdown variants remained possible under specific circumstances.

That said, Intel opted to not provide patches to certain CPUs released between 2007 and 2011 , leaving them vulnerable. If you are using a computer powered by Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, or Yorkfield Xeon CPUs, upgrading to newer hardware is advisable, independent of Spectre or Meltdown.

Intel included hardware-level fixes to some of the variants as part of the Coffee Lake-S Refresh series of workstation CPUs, as well as Xeon Cascade Lake CPUs for servers. AMD is providing fixes starting with Zen 2 CPUs, and Arm has provided hardware-level fixes in Cortex-A76, A53, A55, A32, A7, and A5 designs.

  • Meltdown-Spectre amplifies call for new hardware-software contract (ZDNet)
  • CES 2019: AMD releasing 7nm Ryzen 3 in 2019, while Intel struggles to ship 10nm CPUs (TechRepublic)
  • CES 2019: Intel’s 10nm Ice Lake CPUs, 5G solutions offer greater performance and security (TechRepublic)

specter attack

Subscribe to the Cybersecurity Insider Newsletter

Strengthen your organization's IT security defenses by keeping abreast of the latest cybersecurity news, solutions, and best practices. Delivered Tuesdays and Thursdays

Create a TechRepublic Account

Get the web's best business technology news, tutorials, reviews, trends, and analysis—in your inbox. Let's start with the basics.

* - indicates required fields

Sign in to TechRepublic

Lost your password? Request a new password

Reset Password

Please enter your email adress. You will receive an email message with instructions on how to reset your password.

Check your email for a password reset link. If you didn't receive an email don't forgot to check your spam folder, otherwise contact support .

Welcome. Tell us a little bit about you.

This will help us provide you with customized content.

Want to receive more TechRepublic news?

You're all set.

Thanks for signing up! Keep an eye out for a confirmation email from our team. To ensure any newsletters you subscribed to hit your inbox, make sure to add [email protected] to your contacts list.

  • Generative AI
  • Business Operations
  • IT Leadership
  • Application Security
  • Business Continuity
  • Cloud Security
  • Critical Infrastructure
  • Identity and Access Management
  • Network Security
  • Physical Security
  • Risk Management
  • Security Infrastructure
  • Vulnerabilities
  • Software Development
  • United States
  • United Kingdom
  • Newsletters
  • Foundry Careers
  • Privacy Policy
  • Cookie Policy
  • Member Preferences
  • About AdChoices
  • E-commerce Links
  • Your California Privacy Rights

Our Network

  • Computerworld
  • Network World

Josh Fruhlinger

Spectre and Meltdown explained: What they are, how they work, what’s at risk

Spectre and Meltdown are the names given to a trio of variations on a vulnerability that affects nearly every computer chip manufactured in the last 20 years. The flaws are so fundamental and widespread that security researchers are calling them catastrophic.

thinkstock 500773792 cpu processor

In the first days of 2018, published research revealed that nearly every computer chip manufactured in the last 20 years contains fundamental security flaws, with specific variations on those flaws being dubbed Spectre and Meltdown. The flaws arise from features built into chips that help them run faster, and while software patches are available, they may have impacts on system performance. There is as of yet no evidence that these flaws have been exploited in the wild, but such exploits would be difficult to detect, and the flaws are so fundamental and widespread that security researchers are calling them catastrophic.

What are Spectre and Meltdown?

Spectre and Meltdown are the names given to different variants of the same fundamental underlying vulnerability that affects nearly every computer chip manufactured in the last 20 years and could, if exploited, allow attackers to get access to data previously considered completely protected. Security researchers discovered the flaws late in 2017 and publicized them in early 2018. Technically, there are three variations on the vulnerability, each given its own CVE number ; two of those variants are grouped together as Spectre and the third is dubbed Meltdown .

All of the variants of this underlying vulnerability involve a malicious program gaining access to data that it shouldn’t have the right to see, and do so by exploiting two important techniques used to speed up computer chips, called speculative execution and caching.

What is speculative execution?

Speculative execution essentially involves a chip attempting to predict the future in order to work faster. If the chip knows that a program involves multiple logical branches, it will start working out the math for all of those branches before the program even has to decide between them. For instance, if the program says, “If A is true, compute function X; if A is false, compute function Y”, the chip can start computing both functions X and Y in parallel, before it even knows whether A is true or false. Once it knows whether A is true or false, it already has a head start on what comes after, which speeds up processing overall. Or, in another variation, if a chip learns that a program makes use of the same function frequently, it might use idle time to compute that function even when it hasn’t been asked to, just so it has what it thinks the answer will be on hand.

What is caching?

Caching is a technique used to speed up memory access. It takes a relatively long time for the CPU to fetch data from RAM, which lives on a separate chip, so there’s a special small amount of memory storage called CPU cache on that lives on the CPU chip itself and that can be accessed very quickly. This memory gets filled with data that the chip will need soon, or often. What’s relevant for our situation is that data that’s output by speculative execution is often stored in cache, which is part of what makes speculative execution a speed booster.

The problem arises when caching and speculative execution start grappling with protected memory.

What is protected memory?

Protected memory is one of the foundational concepts underlying computer security. In essence, no process on a computer should be able to access data unless it has permission to do so. This allows a program to keep some of its data private from some of its users, and allows the operating system to prevent one program from seeing data belonging to another. In order to access data, a process needs to undergo a privilege check, which determines whether or not it’s allowed to see that data.

But a privilege check can take a (relatively) long time. So — and this is the key to the vulnerability we’re discussing — while the CPU is waiting to find out if the process is allowed to access that data, thanks to speculative execution, it starts working with that data even before it receives permission to do so. In theory this is still secure, because the results of that speculative execution are also protected at the hardware level. The process isn’t allowed to see them until it passes the privilege check, and if it doesn’t pass the check, the data is discarded.

The problem arises because the protected data is stored in CPU cache even if the process never receives permission to access it. And because CPU cache memory can be accessed more quickly than regular memory, the process can attempt to access certain memory locations to find out if the data there has been cached — it still won’t be able to access the data, but if the data has been cached, its attempt to read it will be rejected much more quickly than it otherwise would. Think of it as knocking on a box to see if it’s hollow. Because of the way computer memory works, just knowing the addresses where data is stored can help you deduce what the data is. This is what’s known as a side-channel attack.

What’s the difference between Spectre and Meltdown?

If you want a much more technical description of how Spectre and Meltdown work, you should check out the post on Google’s Project Zero site that was most of the world’s introduction to it. To keep it short and simple, both Spectre and Meltdown could allow potential attackers to get access to data they shouldn’t have access to using the techniques outlined above, but their effects are somewhat different:

  • Meltdown got its name because it “melts” security boundaries normally enforced by hardware . By exploiting Meltdown, an attacker can use a program running on a machine to gain access to data from all over that machine that the program shouldn’t normally be able to see, including data belonging to other programs and data that only administrators should have access to. Meltdown doesn’t require too much knowledge of how the program the attacker hijacks works, but it only works with specific kinds of Intel chips. This is a pretty severe problem but fixes are being rolled out.
  • By exploiting the Spectre variants, an attacker can make a program reveal some of its own data that should have been kept secret. It requires more intimate knowledge of the victim program’s inner workings, and doesn’t allow access to other programs’ data, but will also work on just about any computer chip out there. Spectre’s name comes from speculative execution but also derives from the fact that it will be much trickier to stop — while patches are starting to become available, other attacks in the same family will no doubt be discovered. That’s the other reason for the name: Spectre will be haunting us for some time.

Why are Spectre and Meltdown dangerous?

Spectre and Meltdown both open up possibilities for dangerous attacks. For instance, JavaScript code on a website could use Spectre to trick a web browser into revealing user and password information. Attackers could exploit Meltdown to view data owned by other users and even other virtual servers hosted on the same hardware, which is potentially disastrous for cloud computing hosts.

But beyond the potential specific attacks themselves lies the fact that the flaws are fundamental to the hardware platforms running beneath the software we use every day. Even code that is formally secure as written turns out to be vulnerable, because the assumptions underlying the security processes built into the code — indeed, built into all of computer programming — have turned out to be false.

Spectre and Meltdown patches

The fundamental vulnerability exists at the hardware level and cannot be patched. However, most vendors are releasing software patches that work around the problems. The KAISER patch, developed coincidentally in 2017 to improve Linux security, actually has the side effect of preventing Meltdown attacks . Major cloud vendors have by and large patched their servers. Patches have already been rolled out by Intel, Microsoft, Apple, and Google (see more below) and more are on the way. CSO’s J.M. Porup has a good roundup of steps you should take in the short term . Rendition Infosec also has a great resource on establishing a strategy for your organization that will, among other things, harden your systems and practices to prevent further damage if you do fall victim to an attack exploiting Spectre or Meltdown.

Since JavaScript in the browser is one particularly dangerous vector for Spectre attacks, it’s also important keep your browsers up to date.

Notably, older systems, particularly Windows XP, will almost certainly never be patched. Also left in the lurch are the millions of third-party, low-cost Android phones that don’t get security updates from Google , many of which are not particularly old.

When will my PC, Mac, iPhone, Android phone, or browser get a patch for Meltdown and Spectre?

  • As of January 11th, Microsoft has released operating system patches for most versions of Windows from Windows 7 on , which also patch the company’s Internet Explorer and Edge browsers. The previous link also includes a roundup of links to firmware updates from hardware manufacturers, which cover all the major players. However, some AMD systems after downloading the patches did not restart, so those patches have been pulled for the moment .
  • Apple released patched versions of its macOS, iOS, and tvOS operating systems , as well as its Safari browser, on January 3rd.
  • Google released a list of which Chromebook models have been patched or won’t need a patch (most of them), which will be patched soon, and which are end-of-lifed and won’t see a patch.
  • Firefox has a patch that will be released on January 23rd , but is now available in beta.
  • Google’s Chrome browser has a patch that will be released on January 23rd . You can turn on the experimental Site Isolation feature in the meantime to protect yourself.
  • The multiplicity of Android handsets makes the question of whether your Android phone is or will be patched difficult to answer. Most phones sold directly from Google or giants like Samsung are patched or will be, but many will not. The Italian trade-in company RiCompo has a site that keeps you up to date on many different brands and models .

Do Spectre and Meltdown patches hurt performance?

These patches generally mitigate the vulnerabilities by altering or disabling how software code makes use of the speculative execution and caching features built into the underlying hardware. The downside of this, of course, is that these features were designed to improve system performance, and so working around them can slow your systems down. While there were initial reports of performance hits up to 30 percent, benchmarks from Phoronix indicate that 5 to 10 percent seems more typical.

Meltdown and Spectre news

Here are the latest headlines from CSO and other publications about this vulnerability. Check back for updates!

  • Patching Windows for Spectre and Meltdown: A complete guide (CSO 8/1/18)
  • Spectre/Meltdown fixes in HPC: Want the bad news or the bad news? (The Register 7/26/18)
  • Google Chrome’s new protection against Meltdown and Spectre bugs will slow your computer down (Mastable 7/13/18)
  • New Spectre-like attack uses speculative execution to overflow buffers (Ars Technica 7/10/2018)
  • New Spectre derivative bug haunts Intel processors (Network World 3/7/18)

Related content

Top cybersecurity product news of the week, over 178,000 sonicwall firewalls still vulnerable to old flaws, london internet attack highlights confusing hacktivism movement, a tougher balancing act in 2024, the year of the ciso, from our editors straight to your inbox.

Josh Fruhlinger

Josh Fruhlinger is a writer and editor who lives in Los Angeles.

More from this author

Defense in depth explained: layering tools and processes for better security, what is an sbom software bill of materials explained, 11 infamous malware attacks: the first and the worst, 9 types of computer virus and how they do their dirty work, most popular authors.

specter attack

Show me more

Softwareprojects exposes substantial customer and affiliate data.

Image

Citrix NetScaler devices face active zero-day exploitations

Image

No digital transformation without cybersecurity

Image

CSO Executive Sessions Australia with Sunil Sale, CISO at MinterEllison

Image

CSO Executive Sessions Australia with Robbie Whittome, CISO at Curtin University

Image

CSO Executive Sessions / ASEAN: Cisco's Anthony Grieco on opportunities in Southeast Asia's cybersecurity landscape

Image

Reaping the Benefits of Security Metrics

Image

Don’t Lose Your Focus: It’s Not About the AI; It’s About the Data

Image

Preventing the Cracks from Becoming a Hole that Becomes a Crater

Image

Sponsored Links

  • Empower workers with a safer, smarter, and more sustainable workspace with a single cloud platform that marries applications and data. Try Cisco Spaces for 30 Days, On Us.
  • Firewalls are designed to protect your security. Speak to a specialist to set up a trial or a demo of Cisco Firewall solutions.
  • Simplify complexity and make better decisions to secure your enterprise. Speak to a specialist to get the details on Cisco Cloud Protection.
  • Don't let budget hold you back. Get more predictive insights from Cisco Full-Stack Observability to resolve issues quicker and optimize user experiences. Schedule a personalized consultation today!
  • Experience the comprehensive solution that provides end-to-end visibility across applications, infrastructure, and network layers. Plus improve your IT operations and enhance overall business performance. Sign up for a Free Trial and explore the benefits.
  • Hybrid work isn't one size fits all. Find the right hybrid work software for your distributed workforce. Prebuilt packages start at just $14.50 per user/month (CSRP—Cisco suggested retail price). Sign up today for a 30-minute, zero-commitment call to explore solutions and pricing for your workforce.
  • Tomorrow’s cybersecurity success starts with next-level innovation today. Join the discussion now to sharpen your focus on risk and resilience.
  • Download this IDC spotlight to learn how to capture new business opportunities more quickly
  • Cisco’s Full-Stack Observability (FSO) solution delivers always-on, secure, and exceptional digital experiences. Book a free, zero-commitment consultation with an expert to learn more about how to make Cisco FSO work for you.
  • Take the guess work out of modernizing your workplace and creating the optimal work environment. Register to access our Design Guides.
  • Mobile Site
  • Staff Directory
  • Advertise with Ars

Filter by topic

  • Biz & IT
  • Gaming & Culture

Front page layout

IT'S BA-ACK! —

New spectre attack once again sends intel and amd scrambling for a fix, a new transient execution variant is the first exploit micro-ops caches..

Dan Goodin - May 4, 2021 7:07 pm UTC

Rows of beautifully colored computer components.

Since 2018, an almost endless series of attacks broadly known as Spectre has kept Intel and AMD scrambling to develop defenses to mitigate vulnerabilities that allow malware to pluck passwords and other sensitive information directly out of silicon. Now, researchers say they’ve devised a new attack that breaks most—if not all—of those on-chip defenses.

Further Reading

“dangerous implications”.

Since Spectre was first described in 2018 , new variants have surfaced almost every month. In many cases, the new variants have required chipmakers to develop new or augmented defenses to mitigate the attacks.

A key Intel protection known as LFENCE, for instance, stops more recent instructions from being dispatched to execution before earlier ones. Other hardware- and software-based solutions broadly known as "fencing" build digital fences around secret data to protect against transient execution attacks that would allow unauthorized access.

Researchers at the University of Virginia said last week that they found a new transient execution variant that breaks virtually all on-chip defenses that Intel and AMD have implemented to date. The new technique works by targeting an on-chip buffer that caches “micro-ops,” which are simplified commands that are derived from complex instructions. By allowing the CPU to fetch the commands quickly and early in the speculative execution process, micro-op caches improve processor speed.

The researchers are the first to exploit the micro-ops cache as a side channel , or as a medium for making observations about the confidential data stored inside a vulnerable computing system. By measuring the timing, power consumption, or other physical properties of a targeted system, an attacker can use a side channel to deduce data that otherwise would be off-limits.

“The micro-op cache as a side channel has several dangerous implications,” the researchers wrote in an academic paper . “First, it bypasses all techniques that mitigate caches as side channels. Second, these attacks are not detected by any existing attack or malware profile. Third, because the micro-op cache sits at the front of the pipeline, well before execution, certain defenses that mitigate Spectre and other transient execution attacks by restricting speculative cache updates still remain vulnerable to micro-op cache attacks."

The paper continues:

Most existing invisible speculation and fencing-based solutions focus on hiding the unintended vulnerable side-effects of speculative execution that occur at the backend of the processor pipeline, rather than inhibiting the source of speculation at the front-end. That makes them vulnerable to the attack we describe, which discloses speculatively accessed secrets through a front-end side channel, before a transient instruction has the opportunity to get dispatched for execution. This eludes a whole suite of existing defenses. Furthermore, due to the relatively small size of the micro-op cache, our attack is significantly faster than existing Spectre variants that rely on priming and probing several cache sets to transmit secret information, and is considerably more stealthy, as it uses the micro-op cache as its sole disclosure primitive, introducing fewer data/instruction cache accesses, let alone misses.

Dissenting voices

There has been some pushback since the researchers published their paper. Intel disagreed that the new technique breaks defenses already put in place to protect against transient execution. In a statement, company officials wrote:

Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels including the uop cache incidental channel. No new mitigations or guidance are needed.

Transient execution uses malicious code to exploit speculative execution. The exploits, in turn, bypass bounds checks, authorization checks, and other security measures built into applications. Software that follows Intel’s secure coding guidelines are resistant to such attacks, including the variant introduced last week.

Key to Intel’s guidance is the use of constant-time programming, an approach where code is written to be secret-independent. The technique the researchers introduced last week uses code that embeds secrets into the CPU branch predictors, and as such, it doesn’t follow Intel's recommendations, a company spokeswoman said on background.

AMD didn’t provide a response in time to be included in this post.

Another rebuff has come in a blog post written by Jon Masters, an independent researcher into computer architecture. He said the paper, particularly the cross-domain attack it describes, is “interesting reading” and a “potential concern” but that there are ways to fix the vulnerabilities, possibly by invalidating the micro-ops cache when crossing the privilege barrier.

“The industry had a huge problem on its hands with Spectre, and as a direct consequence, a great deal of effort was invested in separating privilege, isolating workloads, and using different contexts,” Masters wrote. “There may be some cleanup needed in light of this latest paper, but there are mitigations available, albeit always at some performance cost.”

Not so simple

Ashish Venkat, a professor in the computer science department at the University of Virginia and a co-author of last week’s paper, agreed that constant-time programming is an effective means for writing apps that are invulnerable to side-channel attacks, including those described by last week’s paper. But he said that the vulnerability being exploited resides in the CPU and therefore should receive a microcode patch.

He also said that much of today’s software remains vulnerable because it doesn’t use constant-time programming, and there’s no indication when that will change. He also echoed Masters’ observation that the code approach slows down applications.

Constant-time programming, he told me, “is not only extremely hard in terms of the actual programmer effort but also entails significant deployment challenges related to patching all sensitive software that’s ever been written. It is also typically exclusively used for small, specialized security routines due to the performance overhead.”

Venkat said the new technique is effective against all Intel chips designed since 2011. He told me that besides being vulnerable to the same cross-domain exploit, AMD CPUs are also susceptible to a separate attack. It exploits the simultaneous multithreading design because the micro-op cache in AMD processors is competitively shared. As a result, attackers can create a cross-thread covert channel that can transmit secrets with a bandwidth of 250 Kbps and an error rate of 5.6 percent.

Transient execution poses serious risks, but at the moment, they are mostly theoretical because they’re rarely if ever actively exploited. Software engineers, on the other hand, have much more reason for concern, and this new technique should only increase their worries.

Promoted Comments

Reader comments, channel ars technica.

Google Cloud

Answering your questions about “Meltdown” and “Spectre”

Jan 05, 2018

This week, security vulnerabilities dubbed “Spectre” and “Meltdown” made news headlines. On Wednesday, we explained what these vulnerabilities are and how we're protecting you against them .

Since then, there's been considerable discussion about what this means for Google Cloud and the industry at large. Today, we’d like to clear up some confusion and highlight several key considerations for our customers.

What are “Spectre” and “Meltdown”?

Last year, Google’s Project Zero team discovered serious security flaws caused by “ speculative execution ,” a technique used by most modern processors (CPUs) to optimize performance.

Independent researchers separately discovered and named these vulnerabilities “Spectre” and “Meltdown.” 

Project Zero described three variants of this new class of speculative execution attack. Variant 1 and Variant 2 have been referred to as “Spectre.” Variant 3 has been referred to as “Meltdown.” Most vendors are referring to them by Common Vulnerabilities and Exposures aka “CVE” labels, which are an industry standard way of identifying vulnerabilities.

security-1

There's no single fix for all three attack variants; each requires protection individually.

Here's an overview of each variant:

Variant 1 ( CVE-2017-5753 ), “bounds check bypass.” This vulnerability affects specific sequences within compiled applications, which must be addressed on a per-binary basis. This variant is currently the basis for concern around browser attacks, Javascript exploitation and vulnerabilities within individual binaries.

Variant 2 ( CVE-2017-5715 ), “branch target injection.” This variant may either be fixed by a CPU microcode update from the CPU vendor, or by applying a software protection called “ Retpoline ” to binaries where concern about information leakage is present. This variant is currently the basis for concern around Cloud Virtualization and “Hypervisor Bypass” concerns that affect entire systems.

Variant 3 ( CVE-2017-5754 ), “rogue data cache load.”  This variant is the basis behind the discussion around “KPTI,” or “Kernel Page Table Isolation.” When an attacker already has the ability to run code on a system, they can access memory which they do not have permission to access.

For more information on these variants, please read this week’s Google Security post .

Am I protected from Spectre and Meltdown?  

Google’s engineering teams began working to protect our customers from these vulnerabilities upon our learning of them in June 2017. We applied solutions across the entire suite of Google products , and we collaborated with the industry at large to help protect users across the web.

G Suite and Google Cloud Platform (GCP) are updated to protect against all known attack vectors. Some customers may worry that they have not been protected since they were not asked to reboot their instance. Google Cloud is architected in a manner that enables us to update the environment while providing operational continuity for our customers. Via live migration we can patch our infrastructure without requiring customers to reboot their instances.

Customers who use their own operating systems with Google Cloud services should continue to follow security best practices and apply security updates to their images just as they would for any other operating system vulnerability. We're providing an up-to-date reference on the availability of vendor patches for common operating systems on our GCE Security Bulletin page.

I’ve heard that Spectre is nearly impossible to protect against. Is this true?

There has been significant concern in particular about “Spectre.” The use of the name “Spectre” to refer to both Variants 1 and 2 has caused some confusion over whether it's “fixed” or not.

Google Cloud instances are protected against all known inter-VM attacks, regardless of the patch status of the guest environments, and attackers do not have access to any customers’ data as a result of these vulnerabilities. Google Cloud and other public clouds use virtualization technology to isolate neighboring customer workloads. A virtualization component known as a hypervisor connects the physical machine to virtual machines. This hypervisor can be updated to address Variant 2 threats. Google Cloud has updated its hypervisor using “ Retpoline ,” which addresses all currently known Variant 2 attack methods.

Variant 1 is the basis behind claims that Spectre is nearly impossible to protect against. The difficulty is that Variant 1 affects individual software binaries, so it must be handled by discovering and addressing exploits within each binary.

Risks that Variant 1 would pose to the infrastructure underpinning Google Cloud are addressed by the multiple security controls that make up our layered “defense in depth” security posture. Because Google is in full control of our infrastructure from the hardware up to our secure software development practices, our infrastructure is protected against Variant 1. You can read more about the security foundations of our infrastructure in our whitepaper .

We work continuously to stay ahead of the constantly-evolving threat landscape and will continue to roll out additional protections to address potential risks.

As a user of the public cloud, am I more vulnerable to Spectre and Meltdown than others?

In many respects, public cloud users are better-protected from security vulnerabilities than are users of traditional datacenter-hosted applications. Security best practices rely on discovering vulnerabilities early, and patching them promptly and completely. Each of these activities is aided by the scale and automation that top public cloud providers can offer — for example, few companies maintain a several-hundred-person security research team to find vulnerabilities and patch them before they're discovered by others or disclosed. Having the ability to update millions of servers in days, without causing user disruption or requiring maintenance windows, is difficult technology to develop but it allows patches and updates to be deployed quickly after they become available, and without user disruption that can damage productivity.

Spectre and Meltdown are new and troubling vulnerabilities, but it’s important to remember that there are many different types of threats that Google (and other cloud providers) protect against every single day. Google’s cloud infrastructure doesn’t rely on any single technology to make it secure. Our stack builds security through progressive layers that deliver defense in depth. From the physical premises to the purpose-built servers, networking equipment, and custom security chips to the low-level software stack running on every machine, our entire hardware infrastructure is Google-controlled, -secured, -built and -hardened.

Is performance impacted?

On most of Google’s workloads, including our cloud infrastructure, we've seen negligible impact on performance after applying remediations. This was explained further in our follow-up Security blog post on January 4.

There are many conflicting reports about patch impacts being publicly discussed. In some cases, people have published results of tests that focus solely on making API calls to the operating system, which does not represent the real-world scenario that customer software will encounter. There's no substitute for testing to determine for yourself what performance you can expect in your actual situation. We believe solutions exist that introduce minimal performance impact, and expect such techniques will be adopted by software vendors over time. We designed and tested our mitigations for this issue to have minimal performance impact, and the rollout has been uneventful.

Where can I get additional information?

Technical details from Project Zero about these vulnerabilities

Information about these vulnerabilities and mitigations across all Google products

Additional information about impacts to performance

Our Support page offers a list of affected Google products and will be updated with their current status of mitigation against these risks

Our GCP Security Bulletins page will provide notifications as other operating system maintainers publish patches for this vulnerability and as Compute Engine releases updated OS images

Related stories

21424_ANC_Unpacked blog post header_OP1@3x

The power of Google AI comes to the new Samsung Galaxy S24 series

VS_Hero_3

Five ways Victoria’s Secret & Co. is using AI to make shopping more personalized and inclusive

cloud hero

3 predictions for AI in healthcare in 2024

G Tips Roundup Hero

23 of our most helpful tips from 2023

23 of our biggest moments in 2023.

Gemini_DeveloperCloud_Opt1 (1)

Gemini API and more new AI tools for developers and enterprises

Let’s stay in touch. Get the latest news from Google in your inbox.

Prototype pollution

Prototype pollution project yields another Parse Server RCE

Prototype-pollution

Bug Bounty Radar

The latest programs for February 2023

Bug bounties

All Day DevOps

AppSec engineer keynote says Log4j revealed lessons were not learned from the Equifax breach

DevOps

Infosec beginner?

A rough guide to launching a career in cybersecurity

cyber-career

Cybersecurity conferences

A schedule of events in 2022 and beyond

More topics

Spectre attacks against websites still a serious threat, Google warns

Browser-maker urges web developers to take action against vulnerability that continues to haunt the industry

Spectre security vulnerability still threatens browser security, says Google

UPDATED Three years after the infamous Spectre vulnerability was discovered, hackers can still exploit the security flaw in order to force web browsers to leak information, Google’s security team warns.

The problem has arisen despite extensive efforts by browser developers to harden their software against Spectre-style attacks.

The results of the research was published on the Google Security Blog on Friday (March 12) and include a proof-of-concept exploit written in JavaScript that still works against several browsers, operating systems, and processors.

The key lesson from the research is that Spectre still haunts the industry – so developers need to deploy application-level mitigation measures in order to guard against potential attacks.

The Spectre vulnerability

First reported in 2018, the Spectre vulnerability and its twin, Meltdown , both take advantage of flaws in the optimization features of modern CPUs in order to circumvent the security mechanisms that prevent different processes from accessing each other’s memory space.

The Spectre  vulnerability allowed a wide range of attacks against different types of applications, including web apps. Hackers can potentially exploit the flaws to extract sensitive information across different websites in a browser by exploiting how different applications and processes interact with processors and on-chip memory.

INSIGHT Meltdown and Spectre, one year on: Feared CPU slowdown never really materialized

While newer CPUs have partially mitigated the Spectre vulnerability at the hardware level, there’s still a need for software-based mitigations in order to further limit the scope of potential attacks.

Along with cloud providers and operating system vendors, the developers of web browsers have been putting in efforts to protect users against Spectre attacks.

Their measures include browser protection options such as site isolation and out-of-process iframes, alongside security features that web developers can use to control the origin of resources used in websites.

“These mechanisms, while crucially important, don't prevent the exploitation of Spectre; rather, they protect sensitive data from being present in parts of the memory from which they can be read by the attacker,” the Google Security Team explains.

Hacking the browser

The proof-of-concept (PoC) developed by the Google Security Team exploits the JavaScript engine on Chrome, but the researchers said the same issue applies to other browsers as well.

The PoC is based on a gadget that exploits the “variant 1” Spectre vulnerability across a side-channel that observes the side-effect of the attack.

Variant 1 Spectre, also known as the “bounds check bypass attack”, manipulates the speculative execution mechanisms of processors to access out-of-bounds memory locations.

Read more of the latest security vulnerability news

Side-channels that steal secret data from speculative execution attacks such as Spectre use timing attack techniques to determine the location of the target data. Modern browsers reduce the granularity of their time-measurement functions to prevent such attacks.

The Google Security Team developed a new technique that overcomes this limitation and leaks data with low-precision timers.

The researchers published a demo of their PoC online :

“While we don’t believe this particular PoC can be re-used for nefarious purposes without significant modifications, it serves as a compelling demonstration of the risks of Spectre,” the researchers conclude.

“In particular, we hope it provides a clear signal for web application developers that they need to consider this risk in their security evaluations and take active steps to protect their sites.”

Web developers urged to act

Short of hardware changes and firmware updates, there’s no easy way to develop a comprehensive fix for speculation execution vulnerabilities such as Spectre, the Google Security Team warns.

“Web developers should consider more robustly isolating their sites by using new security mechanisms that actively deny attackers access to cross-origin resources,” the blog post states.

Last year, Google Security published a comprehensive guide on mitigation techniques for different Spectre-style hardware attacks and common web-level cross-site leaks.

But the suggested methods require developers to assess the threat these vulnerabilities pose to their applications and understand how to deploy them, the Security Team notes.

The task is far from straightforward.

To further assist web developers, the Chrome security team has published a lengthy guide on hardening web applications against Spectre attacks .

The guidelines focus on controlling and limiting cross-origin resource sharing and interactions between websites.

The Google Security Team warns that, even if applied rigorously, the mitigation techniques don’t guarantee complete protection against Spectre

“They [the mitigations] require a considered deployment approach which takes behaviors specific to the given application into account,” the researchers advise.

This story was updated to clarify that not even the latest CPUs offer complete protection against Spectre

YOU MIGHT ALSO LIKE Google and Mozilla lay the groundwork for a ‘post-XSS world’

Ben Dickson

Ben Dickson

We’re going teetotal – It’s goodbye to The Daily Swig

Indian gov flaws allowed creation of counterfeit driving licenses, related stories, password managers part ii, chromium bug allowed samesite cookie bypass on android devices.

For IEEE Members

Ieee spectrum, follow ieee spectrum, support ieee spectrum, enjoy more free content and benefits by creating an account, saving articles to read later requires an ieee spectrum account, the institute content is only available for members, downloading full pdf issues is exclusive for ieee members, access to spectrum 's digital edition is exclusive for ieee members, following topics is a feature exclusive for ieee members, adding your response to an article requires an ieee spectrum account, create an account to access more content and features on ieee spectrum , including the ability to save articles to read later, download spectrum collections, and participate in conversations with readers and editors. for more exclusive content and features, consider joining ieee ., join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of spectrum’s articles, archives, pdf downloads, and other benefits. learn more →, access thousands of articles — completely free, create an account and get exclusive content and features: save articles, download collections, and talk to tech insiders — all free for full access and benefits, join ieee as a paying member., how the spectre and meltdown hacks really worked
, an in-depth look at these dangerous exploitations of microprocessor vulnerabilities and why there might be more of them out there.

Illustration: Erik Vrielink

We're used to thinking of computer processors as orderly machines that proceed from one simple instruction to the next with complete regularity. But the truth is, that for decades now, they've been doing their tasks out of order and just guessing at what should come next. They're very good at it, of course. So good in fact, that this ability, called speculative execution, has underpinned much of the improvement in computing power during the last 25 years or so. But on 3 January 2018 , the world learned that this trick, which had done so much for modern computing, was now one of its greatest vulnerabilities.

Throughout 2017, researchers at Cyberus Technology , Google Project Zero , Graz University of Technology , Rambus , University of Adelaide , and University of Pennsylvania , as well as independent researchers such as cryptographer Paul Kocher , separately worked out attacks that took advantage of speculative execution. Our own group had discovered the original vulnerability behind one of these attacks back in 2016, but we did not put all the pieces together.

These types of attacks, called Meltdown and Spectre, were no ordinary bugs. At the time it was discovered, Meltdown could hack all Intel x 86 microprocessors and IBM Power processors, as well as some ARM-based processors. Spectre and its many variations added Advanced Micro Devices ( AMD ) processors to that list. In other words, nearly the whole world of computing was vulnerable.

And because speculative execution is largely baked into processor hardware, fixing these vulnerabilities has been no easy job. Doing so without causing computing speeds to grind into low gear has made it even harder. In fact, a year on, the job is far from over. Security patches were needed not just from the processor makers but from those further down the supply chain, such as Apple , Dell , Linux , and Microsoft . The first computers powered by chips that are intentionally designed to be resistant to even some of these vulnerabilities arrived only recently.

Spectre and Meltdown are the result of the difference between what software is supposed to do and the processor's microarchitecture—the details of how it actually does those things. These two classes of hacks have uncovered a way for information to leak out through that difference. And there's every reason to believe that more ways will be uncovered. We helped find two, Branchscope and SpectreRSB [PDF], last year.

If we're going to keep the pace of computing improvements going without sacrificing security, we're going to have to understand how these hardware vulnerabilities happen. And that starts with understanding Spectre and Meltdown.

How a Pipeline Speeds Computing Using Speculative Execution

In modern computing systems, software programs written in human-understandable languages such as C++ are compiled into assembly-language instructions—fundamental operations that the computer processor can execute. To speed execution, modern processors use an approach called pipelining. Like an assembly line, the pipeline is a series of stages, each of which is a step needed to complete an instruction. Some typical stages for an Intel x 86 processor include those that bring in the instruction from memory and decode it to understand what the instruction means. Pipelining basically brings parallelism down to the level of instruction execution: When one instruction is done using a stage, the next instruction is free to use it.

Since the 1990s, microprocessors have relied on two tricks to speed up the pipeline process: out-of-order execution and speculation. If two instructions are independent of each other—that is, the output of one does not affect the input of another—they can be reordered and their result will still be correct. That's helpful, because it allows the processor to keep working if an instruction stalls in the pipeline. For example, if an instruction requires data that is out in DRAM main memory rather than in the cache memory located in the CPU itself, it might take a few hundred clock cycles to get that data. Instead of waiting, the processor can move another instruction through the pipeline.

The second trick is speculation. To understand it, start with the fact that some instructions necessarily lead to a change in which instructions come next. Consider a program containing an “if" statement: It checks for a condition, and if the condition is true, the processor jumps to a different location in the program. This is an example of a conditional-branch instruction, but there are other instructions that also lead to changes in the flow of instructions.

Now consider what happens when such a branch instruction enters a pipeline. It's a situation that leads to a conundrum. When the instruction arrives at the beginning of the pipeline, we do not know its outcome until it has progressed fairly deep into the pipeline. And without knowing this outcome, we cannot fetch the next instruction. A simple but naive solution is to prevent new instructions from entering the pipeline until the branch instruction reaches a point at which we know where the next instruction will come from. Many clock cycles are wasted in this process, because pipelines typically have 15 to 25 stages. Even worse, branch instructions come up quite often, accounting for upwards of 20 percent of all the instructions in many programs.

To avoid the high performance cost of stalling the pipeline, modern processors use an architectural unit called a branch predictor to guess where the next instruction, after a branch, will come from. The purpose of this predictor is to speculate about a couple of key points. First, will a conditional branch be taken, causing the program to veer off to a different section of the program, or will it continue on the existing path? And second, if the branch is taken, where will the program go—what will be the next instruction? Armed with these predictions, the processor pipeline can be kept full.

Because the instruction execution is based on a prediction, it is being executed “speculatively": If the prediction is correct, performance improves substantially. But if the prediction proves incorrect, the processor must be able to undo the effects of any speculatively executed instructions relatively quickly.

The design of the branch predictor has been robustly researched in the computer-architecture community for many years. Modern predictors use the history of execution within a program as the basis for their results. This scheme achieves accuracies in excess of 95 percent on many different kinds of programs, leading to dramatic performance improvements, compared with a microprocessor that does not speculate. Misspeculation, however, is possible. And unfortunately, it's misspeculation that the Spectre attacks exploit.

Another form of speculation that has led to problems is speculation within a single instruction in the pipeline. That's a pretty abstruse concept, so let's unpack it. Suppose that an instruction requires permission to execute. For instance, an instruction could direct the computer to write a chunk of data to the portion of memory reserved for the core of the operating system. You wouldn't want that to happen, unless it was sanctioned by the operating system itself, or you'd risk crashing the computer. Prior to the discovery of Meltdown and Spectre, the conventional wisdom was that it is okay to start executing the instruction speculatively even before the processor has reached the point of checking whether or not the instruction has permission to do its work.

In the end, if the permission is not satisfied—in our example, the operating system has not sanctioned this attempt to fiddle with its memory—the results are thrown out and the program indicates an error. In general, the processor may speculate around any part of an instruction that could cause it to wait, provided that the condition is eventually resolved and any results from bad guesses are, effectively, undone. It's this type of intra-instruction speculation that's behind all variants of the Meltdown bug, including its arguably more dangerous version, Foreshadow.

The insight that enables speculation attacks is this: During misspeculation, no change occurs that a program can directly observe. In other words, there's no program you could write that would simply display any data generated during speculative execution. However, the fact that speculation is occurring leaves traces by affecting how long it takes instructions to execute. And, unfortunately, it's now clear that we can detect these timing signals and extract secret data from them.

What is this timing information, and how does a hacker get hold of it? To understand that, you need to grasp the concept of side channels. A side channel is an unintended pathway that leaks information from one entity to another (usually both are software programs), typically through a shared resource such as a hard drive or memory.

As an example of a side-channel attack, consider a device that is programmed to listen to the sound emanating from a printer and then uses that sound to deduce what is being printed. The sound, in this case, is a side channel.

In microprocessors, any shared hardware resource can, in principle, be used as a side channel that leaks information from a victim program to an attacker program. In a commonly used side-channel attack, the shared resource is the CPU's cache. The cache is a relatively small, fast-access memory on the processor chip used to store the data most frequently needed by a program. When a program accesses memory, the processor first checks the cache; if the data is there (a cache hit), it is recovered quickly. If the data is not in the cache (a miss), the processor has to wait until it is fetched from main memory, which can take several hundred clock cycles. But once the data arrives from main memory, it's added to the cache, which may require tossing out some other data to make room. The cache is divided into segments called cache sets, and each location in main memory has a corresponding set in the cache. This organization makes it easy to check if something is in the cache without having to search the whole thing.

Cache-based attacks had been extensively researched even before Spectre and Meltdown appeared on the scene. Although the attacker cannot directly read the victim's data—even when that data sits in a shared resource like the cache—the attacker can get information about the memory addresses accessed by the victim. These addresses may depend on sensitive data, allowing a clever attacker to recover this secret data.

How does the attacker do this? There are several possible ways. One variation, called Flush and Reload, begins with the attacker removing shared data from the cache using the “flush" instruction. The attacker then waits for the victim to access that data. Because it's no longer in the cache, any data the victim requests must be brought in from main memory. Later, the attacker accesses the shared data while timing how long this takes. A cache hit—meaning the data is back in the cache—indicates that the victim accessed the data. A cache miss indicates that the data has not been accessed. So, simply by measuring how long it took to access data, the attacker can determine which cache sets were accessed by the victim. It takes a bit of algorithmic magic, but this knowledge of which cache sets were accessed and which were not can lead to the discovery of encryption keys and other secrets.

Meltdown, Spectre, and their variants all follow the same pattern. First, they trigger speculation to execute code desired by the attacker. This code reads secret data without permission. Then, the attacks communicate the secret using Flush and Reload or a similar side channel. That last part is well understood and similar in all of the attack variations. Thus, the attacks differ only in the first component, which is how to trigger and exploit speculation.

Meltdown Attacks

Meltdown attacks exploit speculation within a single instruction. Although assembly-language instructions are typically simple, a single instruction often consists of multiple operations that can depend on one another. For example, memory-read operations are often dependent on the instruction satisfying the permissions associated with the memory address being read. An application usually has permission to read only from memory that's been assigned to it, not from memory allocated to, say, the operating system or some other user's program. Logically, we should check the permissions before allowing the read to proceed, which is what some microprocessors do, notably those from AMD. However, provided the final result is correct, CPU designers assumed that they were free to speculatively execute these operations out of order. Therefore, Intel microprocessors read the memory location before checking permissions, but only “commit" the instruction—making the results visible to the program—when the permissions are satisfied. But because the secret data has been retrieved speculatively, it can be discovered using a side channel, making Intel processors vulnerable to this attack.

The Foreshadow attack is a variation of the Meltdown vulnerability. This attack affects Intel microprocessors because of a weakness that Intel refers to as L1 Terminal Fault (L1TF). While the original Meltdown attack relied on a delay in checking permissions, Foreshadow relies on speculation that occurs during a stage of the pipeline called address translation.

Software views the computer's memory and storage assets as a single contiguous stretch of virtual memory all its own. But physically, these assets are divided up and shared among different programs and processes. Address translation turns a virtual memory address into a physical memory address.

Specialized circuits on the microprocessor help with the virtual-to-physical memory-address translation, but it can be slow, requiring multiple memory lookups. To speed things up, Intel microprocessors allow speculation during the translation process, allowing a program to speculatively read the contents of a part of the cache called L1 regardless of who owns that data. The attacker can do this, and then disclose the data using the side-channel approach we already described.

In some ways Foreshadow is more dangerous than Meltdown, in other ways it is less. Unlike Meltdown, Foreshadow can read the contents only of the L1 cache, because of the specifics of Intel's implementation of its processor architecture. However, Foreshadow can read any contents in L1—not just data addressable by the program.

Spectre Attacks

Spectre attacks manipulate the branch-prediction system. This system has three parts: the branch-direction predictor, the branch-target predictor, and the return stack buffer.

The branch-direction predictor predicts whether a conditional branch, such as one used to implement an “if" statement in a programming language, will be taken or not taken. To do this, it tracks the previous behavior of similar branches. For example, it may mean that if a branch is taken twice in a row, future predictions will say it should be taken.

The branch-target predictor predicts the target memory address of what are called indirect branches. In a conditional branch, the address of the next instruction is spelled out, but for an indirect branch that address has to be computed first. The system that predicts these results is a cache structure called the branch-target buffer. Essentially, it keeps track of the last computed target of the indirect branches and uses these to predict where the next indirect branch should lead to.

The return stack buffer is used to predict the target of a “return" instruction. When a subroutine is “called" during a program, the return instruction makes the program resume work at the point from which the subroutine was called. Trying to predict the right point to return to based only on prior return addresses won't work, because the same function may be called from many different locations in the code. Instead, the system uses the return stack buffer, a piece of memory on the processor, that keeps the return addresses of functions as they are called. It then uses these addresses when a return is encountered in the subroutine's code.

Each of these three structures can be exploited in two different ways. First, the predictor can be deliberately mistrained. In this case, the attacker executes seemingly innocent code designed to befuddle the system. Later, the attacker deliberately executes a branch that will misspeculate, causing the program to jump to a piece of code chosen by the attacker, called a gadget. The gadget then sets about stealing data.

A second manner of Spectre attack is termed direct injection. It turns out that under some conditions the three predictors are shared among different programs. What this means is that the attacking program can fill the predictor structures with carefully chosen bad data as it executes. When an unwitting victim executes their program either at the same time as the attacker or afterward, the victim will wind up using the predictor state that was filled in by the attacker and unwittingly set off a gadget. This second attack is particularly worrisome because it allows a victim program to be attacked from a different program. Such a threat is especially damaging to cloud-service providers because they cannot then guarantee that their client data is protected.

The Spectre and Meltdown vulnerabilities presented a conundrum to the computing industry because the vulnerability originates in hardware. In some cases the best we can do for existing systems—which make up the bulk of installed servers and PCs—is to try to rewrite software to attempt to limit the damage. But these solutions are ad hoc, incomplete, and often result in a big hit to computer performance. At the same time, researchers and CPU designers have started thinking about how to design future CPUs that keep speculation without compromising security.

One defense, called kernel page-table isolation (KPTI) [PDF], is now built into Linux and other operating systems. Recall that each application views the computer's memory and storage assets as a single contiguous stretch of virtual memory all its own. But physically, these assets are divided up and shared among different programs and processes. The page table is essentially the operating system's map, telling it which parts of a virtual memory address correspond to which physical memory addresses. The kernel page table is responsible for doing this for the core of the operating system. KPTI and similar systems defend against Meltdown by making secret data in memory, such as the OS, inaccessible when a user's program (and potentially an attacker's program) is running. It does this by removing the forbidden parts from the page table. That way, even speculatively executed code cannot access the data. However, this solution means extra work for the operating system to map these pages when it executes and unmap them afterward.

Another class of defenses gives programmers a set of tools to limit dangerous speculation. For example, Google's Retpoline patch rewrites the kind of branches that are vulnerable to Spectre Variant 2, so that it forces speculation to target a benign, empty gadget. Programmers can also add an assembly-language instruction that limits Spectre v1, by restricting speculative memory reads that follow conditional branches. Conveniently, this instruction is already present in the processor architecture and is used to enforce the correct ordering between memory operations originating on different processor cores.

As the processor designers, Intel and AMD had to go deeper than a regular software patch. Their fixes update the processor's microcode. Microcode is a layer of instructions that fits between the assembly language of regular software and the processor's actual circuitry. Microcode adds flexibility to the set of instructions a processor can execute. It also makes it simpler to design a CPU because when using microcode, complex instructions are translated to multiple simpler instructions that are easier to execute in a pipeline.

Basically, Intel and AMD adjusted their microcode to change the behavior of some assembly-language instructions in ways that limit speculation. For example, Intel engineers added options that interfere with some of the attacks by allowing the operating system to empty the branch-predictor structures in certain circumstances.

Some Speculative Executions Vulnerabilities

A different class of solutions attempts to interfere with the attacker's ability to transmit the data out using side channels. For example, MIT's DAWG technology securely divides up the processor cache so that different programs don't share any of its resources. Most ambitiously, there are proposals for new processor architectures that would introduce structures on the CPU that are dedicated to speculation and separate from the processor's cache and other hardware. This way, any operations that are executed speculatively but are not eventually committed are never visible. If the speculation result is confirmed, the speculative data is sent to the processor's main structures.

Speculation vulnerabilities have lain dormant in processors for over 20 years, and they remained, so far as anyone knows, unexploited. Their discovery has substantially shaken industry and highlighted how cybersecurity is not only a problem for software systems but for hardware as well. Since the initial discovery, around a dozen variants of Spectre and Meltdown have been revealed, and it is likely that there are more. Spectre and Meltdown are, after all, side effects of core design principles that we have relied on to improve computer performance, making it difficult to eliminate such vulnerabilities in current system designs. It is likely that new CPU designs will evolve to retain speculation, while preventing the type of side-channel leakage that enables these attacks. Nevertheless, future computer-system designers, including those designing processor chips, must be aware of the security implications of their decisions, and no longer optimize only for performance, size, and power.

About the Author

Nael Abu-Ghazaleh is chair of the computer engineering program at the University of California, Riverside. Dmitry Evtyushkin is an assistant professor of computer science at the College of William and Mary, in Williamsburg, Va. Dmitry Ponomarev is a computer science professor at the State University of New York at Binghamton.

To Probe Further

Paul Kocher and the other researchers who collectively disclosed Spectre first explained it here [PDF]. Moritz Lipp explained Meltdown in this talk at Usenix Security '18 . Foreshadow was detailed at the same conference.

A group of researchers including one of the authors have come up with a systematic evaluation of Spectre and Meltdown attacks that uncovers additional potential attacks [PDF]. IBM engineers did something similar , and Google engineers recently came to the conclusion that side-channel and speculative execution attacks are here to stay [PDF].

  • This AI Can Tell What You're Typing Based on the Sound - IEEE Spectrum ›

This article is for IEEE members only. Join IEEE to access our full archive.

Membership includes:.

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions
  • My Kaspersky
  • My Products / Subscriptions
  • Solutions for:

Privacy & Kids

specter attack

Spectre vulnerability: 4 years after discovery

Does hardware vulnerabilities in CPU pose a practical threat to businesses?

' src=

February 1, 2022

specter attack

Four years have passed since the first publication of the research on Spectre and Meltdown, hardware vulnerabilities in modern processors. Since then, researchers discovered several similar flaws, that are potentially capable of leaking confidential data. The researchers also showed examples of attacks using these vulnerabilities, although most of them are unlikely to be used in the wild. In this post we look at the state of these hardware issues today and on their potential use to attack businesses.

Several variants of Spectre

The original August 2018 announcement revealed three vulnerabilities: Spectre v1 and v2, and Meltdown. Those vulnerabilities have several common features:

  • Their exploitation usually involves the execution of malicious code on a vulnerable system, albeit with low privileges. The most dangerous option is an attack through a browser when visiting an “infected” web page.
  • Practical exploitation requires a number of conditions, in particular, the code of the attacked application must allow data leakage, have a so-called “gadget,” access to which makes the attack possible.
  • The data leak itself occurs through side channels. Because of this, the speed of the data leak is extremely low.
  • A successful attack may leave no traces of unauthorized data access at all.

The last argument is precisely what aroused particular interest in this seemingly theoretical scientific work. In all cases, researchers exploited the branch prediction system. This mechanism was introduced more than 20 years ago, it allows you to speed up performance by executing a set of instructions even before an explicit request for their execution from the program. If the prediction was correct, the processor resources will be used more efficiently. If the prediction is wrong, the calculations are just discarded.

POC for the Spectre v1 showed that the processor will read data that should be inaccessible by the program. It is stored in the cache and can be retrieved from there through side channels. This mechanism was considered safe, because that erroneously read “secret” was not transmitted to the program. But researchers have found ways to indirectly read that data.

After the publication of work on Spectre and Meltdown, several more similar vulnerabilities were discovered. Researchers continue to look for new methods for extracting secret data by exploiting the vulnerabilities of processors. Intel’s summary table lists more than 20 of these issues, in addition to the original three.

How to fight Spectre

Theoretically there are three ways to make a processor vulnerability less exploitable: vendors can issue a microcode update for existing processors, they can modify new CPUs, or try to solve the problem through the software updates. Often true mitigation requires a combination of firmware and software updates. The new microcode covering some of the vulnerabilities has been available for Intel processors since the 2013 Haswell generation. Hardware solutions were first implemented in the eighth generation of Intel processors, as well as in AMD’s Zen 2 CPUs.

Software solutions can be quite tricky: as an example, you can look at the possible modifications in the Linux kernel against Spectre v1 and v2. A wide range of measures were discussed, depending on the goals and objectives of a particular system, including the complete disabling of speculative code execution with serious consequences for CPU performance.

For most organizations whose business model depends on the performance of a large fleet of servers such performance drop will be the most noticeable impact of anti-Spectre measures. A relatively recent benchmark on the Phoronix website, which examines the performance of various server applications, shows a 25% performance decrease on average when all anti-Spectre precautions in the Linux OS are enabled.

Practical attacks and proofs of concept

Despite the large number of attack types, the threat of data theft using Spectre is still theoretical. Although each research contains some code that demonstrates the leak, this does not mean that this code can be used against a real system. The typical limitations of these demos or proof of concept are as follows:

  • They demonstrate a random data leak. It may not have a practical value, it is just random information that the attacker did not previously have access to.
  • Researchers created ideal conditions for the attack. For example, they had an unlimited access to the system. In this case, it is not necessary to use complex data exfiltration methods.
  • It demonstrates a real data breach, but in highly unlikely conditions.

The most impressive theoretical work (in terms of possible consequences) is the NetSpectre attack. The researchers managed to demonstrate remote exploitation with data exfiltration at a speed of 15 to 60 bits per hour. The limitations of the attack are clear: low data transmission rate, exfiltrated data contains a huge amount of junk traffic, plus vulnerable code on the attacked server “in the right place” for success.

Two practical attacks, as close as possible to ITW conditions, were shown last year. In March, Google showed a leaky.page concept: a web page that can extract data from the RAM. In September, a Spook.js attack on the latest (at the time of research) version Google Chrome (92) with Spectre protection (isolation of web pages in separate browser processes) was demonstrated. This method allowed real data theft: researchers accessed credentials for a social network, password manager data, and an image uploaded by a user to a private cloud. But in all that cases, the successful data lead required to have an “infected” page located on the same domain. For example, stealing a Tumblr password involves uploading malicious Javascript code to another page on the same social network.

So how dangerous is the threat?

The Spook.js was neutralized with a software patch for the Google Chrome browser. Therefore, at this moment, there is no immediate threat of exploitation of Spectre vulnerabilities in real conditions. All known attacks are extremely complex and require the highest skill of the attacker.

Most realistic proofs of concept were patched, and even without patches, their exploitation requires a large set of conditions. Even though media reports about real “Spectre exploits” have not been confirmed , security vendors have added tools to detect known attacks just in case, so most likely existing malware detection mechanisms can help to protect your company.

However, we should not completely ignore the Spectre: it is important that research continues. There is a small chance that over time, the “worst-case scenario” will be discovered: an attack that does not require installation of malware that allows to data leak that leaves no trace.

Theoretically it is possible to conduct a targeted attack using hardware vulnerabilities if the value of the stolen data justifies it. Protection against such risks requires serious investments in identifying potential attack vectors, following the recommendations of OS developers, or implementing protection even at the cost of a serious performance drop. But for most, even large companies, it is enough to rely on the software and operating system developers, processor manufacturers, and security solutions .

How to block cookies in Chrome, Safari, Firefox and Edge

How to block cookies in your browser

Here’s how to configure cookies in Chrome, Safari, Firefox and Edge.

specter attack

Are your TV, smartphone, and smart speakers eavesdropping on you?

Advertising firms boast that they can listen in on conversations through smart TVs and smartphones. Is this true, and, if so — how can you avoid being snooped on?

The principle of least privilege: what is it and why is it needed?

What’s the principle of least privilege, why’s it needed, and how does it help secure corporate information assets?

Kick off the year with a digital cleanup

Let’s start the New Year with a digital cleanup: canceling unnecessary subscriptions, clearing out unnecessary data, deleting unused accounts, changing weak passwords, and so on.

Cybersecurity resolutions: how to make 2024 safer

Cybersecurity trends to consider and new threats to protect against in 2024.

Sign up to receive our headlines in your inbox

  • Email Address *
  • I agree to provide my email address to “AO Kaspersky Lab” to receive information about new posts on the site. I understand that I can withdraw this consent at any time via e-mail by clicking the “unsubscribe” link that I find at the bottom of any e-mail sent to me for the purposes mentioned above.

Home Solutions

  • Kaspersky Standard
  • Kaspersky Plus
  • Kaspersky Premium
  • All Solutions

Small Business Products

  • Kaspersky Small Office Security
  • Kaspersky Endpoint Security Cloud
  • All Products

Medium Business Products

  • Kaspersky Endpoint Security for Business Select
  • Kaspersky Endpoint Security for Business Advanced

Insights / Information Technology / Article

5 ways to prevent a spectre or meltdown attack.

March 15, 2018

Contributor: Wunmi Bamiduro

How enterprises can safeguard customers personal data and information stored on PCs

The discovery of the Spectre and Meltdown threats came as a shock to most individuals and organizations. The underlying vulnerabilities that they exposed continue to affect PCs, smartphones, servers, network and security appliances, and some IoT devices — anything that requires a central processing unit (CPU) to function is at risk of loss of the sensitive information held in its memory. As CPUs are foundational to everything in IT, the programs and operating tasks of everyday devices and the secrets they hold are susceptible. Not since Y2K has a vulnerability affected so many systems and required a deliberate, phased plan of action for remediation efforts.

“ By the end of 2019, we can expect to see more variants of attacks  that exploit speculative execution and require additional remediation. ”

“The risk is real, but with a clear and pragmatic risk-based remediation plan, information security and risk management leaders can provide business leaders with confidence that the marginal risk to the enterprise is manageable and is being addressed,” says Neil MacDonald , vice president and distinguished analyst at Gartner.

Although patches have addressed the current Spectre and Meltdown issues, they may not be the best solution. By the end of 2019, we can expect to see more variants of attacks that exploit speculative execution and require additional remediation.

To defend against Spectre and Meltdown, MacDonald recommends security leaders take the following steps:

  • Create a detailed inventory: Nearly every modern IT system will be affected to some extent. The starting point for security leaders must be to inventory all affected systems.
  • Develop and prioritize remediation efforts: The vulnerabilities are not remotely exploitable. A successful attack requires the attacker to execute code on the system. Whitelisting and application controls on all systems will reduce the risk of unknown code execution.
  • Recognize that patches are not always the right answer: Information security leaders must be prepared for scenarios in which a patch is not a solution. There will be a lack of patches for older systems. Patches might also fail because the impact on performance is not offset by the reduction in risk, such as with network and storage controllers.
  • Be diligent about hygiene: For systems that are not patched or only partially patched, multiple mitigating controls can reduce risk. “The single most important issue to address is restricting the ability to place untrusted/unknown code onto the device. By doing this, we significantly reduce the risk , because attacks require local code execution — for Spectre and Meltdown — and any future attacks,” says MacDonald.
  • Plan for the future, not the past: This is not the last we will see of these issues . The underlying exploitable implementation is still present and will remain so for years to come. Further research on this design flaw — involving speculative execution to discover new types of attacks— is expected and will likely require additional patches for hypervisors, OSs, browsers and firmware upgrades during the next several years.

Experience IT Security and Risk Management conferences

Join your peers for the unveiling of the latest insights at Gartner conferences.

Recommended resources for Gartner clients*:

Security Leaders Need to do Seven Things to Deal With Spectre/Meltdown  by Neil MacDonald.

*Note that some documents may not be available to all Gartner clients.

Get Exclusive Content

3 must-haves in your cybersecurity incident response, security leaders to embrace remote security ops, gartner cloud security cookbook: build your strategy and architecture, subscribe to the latest insight.

By clicking the "Continue" button, you are agreeing to the Gartner Terms of Use and Privacy Policy.

  • Audit and Risk
  • Customer Service and Support
  • Technology/Service Providers
  • Human Resources
  • Information Technology Professional
  • Investment Professional
  • Legal and Compliance
  • Marketing and Communications
  • Marketing at a Technology/Service Provider
  • Procurement
  • Research and Development
  • Supply Chain

Please provide the consent below

I have read, understood and accepted Gartner Separate Consent Letter , whereby I agree (1) to provide Gartner with my personal information, and understand that information will be transferred outside of mainland China and processed by Gartner group companies and other legitimate processing parties and (2) to be contacted by Gartner group companies via internet, mobile/telephone and email, for the purposes of sales, marketing and research.

By clicking the "Subscribe" button, you are agreeing to the Gartner Terms of Use and Privacy Policy.

Explore deep-dive content to help you stay informed and up to date

The gartner top trends in ai public policy and regulations for 2024, apply generative ai for new competitive advantages, ask the expert: the art of the 1-page strategy - 4 simple steps to success, how executives can prepare for the future of leadership, impactful storytelling: craft a business value and human value story to increase influence, drive stronger performance on your mission-critical priorities..

Spectre Attacks: Exploiting Speculative Execution

Ieee account.

  • Change Username/Password
  • Update Address

Purchase Details

  • Payment Options
  • Order History
  • View Purchased Documents

Profile Information

  • Communications Preferences
  • Profession and Education
  • Technical Interests
  • US & Canada: +1 800 678 4333
  • Worldwide: +1 732 981 0060
  • Contact & Support
  • About IEEE Xplore
  • Accessibility
  • Terms of Use
  • Nondiscrimination Policy
  • Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

  • 90% Refund @Courses
  • Trending Now
  • Data Structures & Algorithms
  • Foundational Courses
  • Data Science
  • Practice Problem
  • Machine Learning
  • DevOps Tutorial
  • System Design
  • Web Development
  • Web Browser

Related Articles

  • Explore Our Geeks Community
  • Meltdown Security Vulnerability
  • How to Unlock the Power of Critical Thinking: 7 Proven Ways
  • 5 Ways to Make Online Education Effective in 2020
  • DevOps Certification - A Way to Enhance Growth Opportunities
  • Top 10 Highest Paying IT Jobs in India 2024
  • Plan Your Placement Strategy With Love Babbar
  • How to Effectively Use Storytelling in Job Interviews
  • 7 Most In-Demand Digital Marketing Job Roles For Freshers
  • How to Build an Impressive Web Developer Portfolio?
  • 5 Steps to Learn to Code in Any Programming Language
  • 9 Common Interview Questions & Answers For Freshers (2023)
  • Best Internship And Full Time Career Opportunities Programs for Women
  • 5 Video Optimisation and Management Toolkit
  • Top 10 Python GUI Frameworks for Developers
  • How to Make a Great LinkedIn Profile: 12 Easy Steps
  • How to learn any technology inside out?
  • Is Testing on Internet Explorer Still Relevant?
  • Top 5 Free Online IDE, Compilers in 2020
  • Top 15 Service Based Companies in India To Apply in 2023

Spectre Security Vulnerability

What is Spectre security vulnerability?

Spectre is a security vulnerability that affects all modern processors that use mechanisms such as branch prediction and speculative action.  Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side-channel to the adversary. This also exposes otherwise protected memory space, allowing the malicious agent to access the data, or even modify it. It was discovered at the same time as Meltdown Vulnerability .   

What are Branch Prediction and Speculative Action mechanisms?

  • Branch Prediction: The branch prediction technique allows the processor to speed up the execution in a pipelined processor by converting instructions into predicate logic. Hence, only those instructions are executed whose predicate is true. This allows the CPU to avoid checking every single branch for execution.
  • Speculative Execution: Speculative Execution, along with branch prediction, is a component of out-of-order execution that is used for speeding up execution in pipeline-based microprocessors. We learned from the previous definition that branch prediction is used to determine which instruction will execute in case of a conditional jump. Speculative action goes one step further. It determines what the result would be from executing the next instruction(s). If the branch prediction was correct, the result is used, otherwise, it is discarded.  

How does Spectre Vulnerability work?

There are two ways in which Spectre Vulnerability works:  1. Local exploitation:  In this case, the malicious agent lies in the computer itself. The following are the steps that occur:  

  • It manipulates the process to execute an instruction that would never have been executed normally
  • When the CPU evaluates the executed instruction, it throws away the computation.
  • However, the expanded size of the cache isn’t restored.
  • By simply looking up into the cache, the contents which were there, and their actual memory location can be deduced, thus exposing them to the malicious program

2. Remote Exploitation:  In this case, the malicious agent works through Javascript. The scripted malware gets access to all the memory-mapped with the browser. The following steps are taken:  

  • The cache is forced to be flushed by doing incremental reads on large datasets because array memories in javascript are maintained using the LRU policy.
  • The branch predictor would then be mistrained by iterating over a very large dataset using bitwise operations for setting the index to in-range values, and then using an out-of-bounds address for the final iteration.
  • By iterating over a large dataset by using bitwise operations to set in-range values, and using out of bounds addresses for the final iteration, the branch predictor can be mistrained
  • Timed-reads enable the script to read the location

What mitigation steps are being taken?

The discovery of this security issue leads to many prevention and mitigation measures to be developed. Different processor and software vendors addressed the issue differently in the following ways:  

  • In March 2018, Intel developed hardware fixes for Spectre. The vulnerabilities were mitigated by a new partitioning system that improves the process and privilege-level separation.
  • Microsoft acted by isolating Kernel and user page tables. It has also designed new CPU instructions (Windows compatible) which eliminate branch speculation.
  • Chrome 64 includes mitigation against the attack by default. Chrome 63 users can manually mitigate the attack by enabling the Site Isolation feature (chrome://flags#enable-site-per-process)
  • Google created a new technique called ‘Retpoline’ that involves compiler-level steering of indirect branches towards a different target that does not result in a vulnerable speculative out-of-order execution taking place.
  • Mozilla is reducing the resolution of JavaScript timers to help prevent timing attacks, with additional work on time-fuzzing techniques planned for future releases.

It is, however, to be noted that the introduction of software patches has led to significant performance issues, especially on old computers. Also, unwanted reboots have been reported even for newer Intel chips. 

References:   https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)  

https://www.csoonline.com/article/3247868/vulnerabilities/spectre-and-meltdown-explained-what-they-are-how-they-work-whats-at-risk.html

Please Login to comment...

  • varshagumber28
  • harshmaster07705
  • 12 Top Generative AI Tools (2024)
  • Top 10 Oldest Languages In The World
  • 10 Top AI Audio Enhancer Tools in 2024 [Free & Paid]
  • 10 Top AI Audio Restoration Tools - 2024 [Free]
  • 10 Best Free AI Art Generators to Create Image From Text [Free & Paid]

Improve your Coding Skills with Practice

 alt=

What kind of Experience do you want to share?

To revist this article, visit My Profile, then View saved stories .

  • Backchannel
  • Wired World
  • Artificial Intelligence
  • Newsletters
  • Wired Insider

Lily Hay Newman Matt Burgess

A Flaw in Millions of Apple, AMD, and Qualcomm GPUs Could Expose AI Data

AI brain

As more companies ramp up development of artificial intelligence systems, they are increasingly turning to graphics processing unit (GPU) chips for the computing power they need to run large language models (LLMs) and to crunch data quickly at massive scale. Between video game processing and AI, demand for GPUs has never been higher, and chipmakers are rushing to bolster supply . In new findings released today, though, researchers are highlighting a vulnerability in multiple brands and models of mainstream GPUs —including Apple, Qualcomm, and AMD chips—that could allow an attacker to steal large quantities of data from a GPU’s memory.

The silicon industry has spent years refining the security of central processing units, or CPUs, so they don’t leak data in memory even when they are built to optimize for speed. However, since GPUs were designed for raw graphics processing power, they haven’t been architected to the same degree with data privacy as a priority. As generative AI and other machine learning applications expand the uses of these chips, though, researchers from New York–based security firm Trail of Bits say that vulnerabilities in GPUs are an increasingly urgent concern.

“There is a broader security concern about these GPUs not being as secure as they should be and leaking a significant amount of data,” Heidy Khlaaf, Trail of Bits’ engineering director for AI and machine learning assurance, tells WIRED. “We’re looking at anywhere from 5 megabytes to 180 megabytes. In the CPU world, even a bit is too much to reveal.”

To exploit the vulnerability, which the researchers call LeftoverLocals , attackers would need to already have established some amount of operating system access on a target’s device. Modern computers and servers are specifically designed to silo data so multiple users can share the same processing resources without being able to access each others’ data. But a LeftoverLocals attack breaks down these walls. Exploiting the vulnerability would allow a hacker to exfiltrate data they shouldn’t be able to access from the local memory of vulnerable GPUs, exposing whatever data happens to be there for the taking, which could include queries and responses generated by LLMs as well as the weights driving the response.

In their proof of concept , as seen in the GIF below, the researchers demonstrate an attack where a target—shown on the left—asks the open source LLM Llama.cpp to provide details about WIRED magazine. Within seconds, the attacker’s device—shown on the right—collects the majority of the response provided by the LLM by carrying out a LeftoverLocals attack on vulnerable GPU memory. The attack program the researchers created uses less than 10 lines of code.

Last summer, the researchers tested 11 chips from seven GPU makers and multiple corresponding programming frameworks. They found the LeftoverLocals vulnerability in GPUs from Apple, AMD, and Qualcomm, and launched a far-reaching coordinated disclosure of the vulnerability in September in collaboration with the US-CERT Coordination Center and the Khronos Group, a standards body focused on 3D graphics, machine learning, and virtual and augmented reality.

The researchers did not find evidence that Nvidia, Intel, or Arm GPUs contain the LeftoverLocals vulnerability, but Apple, Qualcomm, and AMD all confirmed to WIRED that they are impacted. This means that well-known chips like the AMD Radeon RX 7900 XT and devices like Apple’s iPhone 12 Pro and M2 MacBook Air are vulnerable. The researchers did not find the flaw in the Imagination GPUs they tested, but others may be vulnerable.

An Apple spokesperson acknowledged LeftoverLocals and noted that the company shipped fixes with its latest M3 and A17 processors, which it unveiled at the end of 2023. This means that the vulnerability is seemingly still present in millions of existing iPhones, iPads, and MacBooks that depend on previous generations of Apple silicon. On January 10, the Trail of Bits researchers retested the vulnerability on a number of Apple devices. They found that Apple’s M2 MacBook Air was still vulnerable, but the iPad Air 3rd generation A12 appeared to have been patched.

A Qualcomm spokesperson told WIRED that the company is “in the process” of providing security updates to its customers, adding, “We encourage end users to apply security updates as they become available from their device makers.” The Trail of Bits researchers say Qualcomm confirmed it has released firmware patches for the vulnerability.

AMD released a security advisory on Wednesday detailing its plans to offer fixes for LeftoverLocals. The protections will be “optional mitigations” released in March.

For its part, Google says in a statement that it “is aware of this vulnerability impacting AMD, Apple, and Qualcomm GPUs. Google has released fixes for ChromeOS devices with impacted AMD and Qualcomm GPUs.”

The Trail of Bits researchers caution that actually getting these various fixes to proliferate will not be easy. Even when GPU makers release usable patches, the device makers that incorporate their chips into personal computers and other devices must then package and relay the protections to end users. With so many players in the global tech ecosystem, it’s difficult to coordinate all parties.

Though exploiting the vulnerability would require some amount of existing access to targets’ devices, the potential implications are significant given that it is common for highly motivated attackers to carry out hacks by chaining multiple vulnerabilities together. Furthermore, establishing “initial access” to a device is already necessary for many common types of digital attacks.

“If you manage to get on the same system, you can just listen in on somebody and the responses of the LLM chat session—this was a straightforward thing to do,” says Tyler Sorensen, the security research engineer at Trail of Bits who found the vulnerability and is a security engineering researcher at the University of California, Santa Cruz.

The researchers note that leaks from machine learning processes in other applications could be very sensitive—for example, if a mobile medical health app is incorporating AI patient support. But a GPU could process any number of things, and data privacy in memory is a foundational element that must be built into silicon from the start. In the six years since disclosure of the Spectre and Meltdown CPU processor vulnerabilities, chipmakers have invested significant energy into strengthening and refining memory protections, not just through firmware patches for existing chips, but by making physical improvements to how CPUs are designed. These hardware changes take years to implement because the manufacturing pipeline is planned far in advance.

“If a user is running on the same local machine as malicious software, then the final contents of the GPU program scratchpad memory that is used for temporary storage of data during operation could be viewable by a bad actor,” AMD said of the Trail of Bits research. The company stipulated that “AMD also believes there is no exposure to any other part of the system and no user data is compromised.”

In practice, though, years of processor memory vulnerabilities have illustrated the potential risks and the importance of addressing such flaws. “We have seen these leaks that have been patched, that were revealing things like web browser data and that’s very sensitive,” Trail of Bits’ Khlaaf says, referring to past examples of memory-related leaks from chips.

In recent months, other findings about GPU insecurity have underscored the potential threat of information leakage in these increasingly popular and vital processors. As generative AI has boomed in the past 18 months, companies have raced to buy—and in some cases build their own—faster and more capable GPUs. The Trail of Bits researchers say the LeftoverLocals vulnerability highlights that many of the components needed to develop and run machine learning in general have “unknown security risks” and “have not been rigorously reviewed by security experts.”

The researchers say that LeftoverLocals is part of a crucial movement to raise awareness about the need for GPU security refinements similar to those that have been implemented for CPUs. This is especially pressing as more vendors, like Apple, incorporate CPUs and GPUs together for maximum efficiency in schemes known as “systems-on-a-chip,” or SoCs.

“The GPU has access to that full memory and, as we’re seeing, can be quite insecure,” Trail of Bits’ Sorensen says. “Rather than having it separated out, you're just dropping it into the thick of it in a SoC. And so we need to think hard about GPU security, especially in that context where the GPU now potentially has access to CPU memory as well.”

The researchers also caution that GPU memory security issues and vulnerabilities like LeftoverLocals will become even more consequential as GPU virtualization becomes more common in public cloud infrastructure and more AI applications move from being implemented locally to running in shared cloud environments. Without significant reforms in GPU memory privacy, these transitions could create fertile ground for attackers to easily grab large amounts of data from numerous targets in a single attack.

“I think we came across this at the right time,” Sorensen says. “A lot of the major cloud providers do not allow multiple users on the same GPU machine, but this is likely something that will change going forward. So I think we just need to be hyperaware of this and have more of a security model for GPUs and how they are deployed. This should inspire people to say, ‘We need to be careful when we do this.’”

You Might Also Like …

📨 Make the most of chatbots with our AI Unlocked newsletter

How not to be stupid about AI , with Yann LeCun

Blood, guns, and broken scooters: The chaotic rise and fall of Bird

The year the millennial internet died

Women in the US are stockpiling abortion pills

What it’s like to use Apple’s Lockdown Mode

🔌 Charge right into travel season with the best travel adapters , power banks , and USB hubs

specter attack

  • CVE DATABASE
  • VISIT SENTINELONE.COM

Exploring FBot  | Python-Based Malware Targeting Cloud and Payment Services

Executive summary.

  • FBot is a Python-based hacking tool distinct from other cloud malware families, targeting web servers, cloud services, and SaaS platforms like AWS, Office365, PayPal, Sendgrid, and Twilio.
  • FBot does not utilize the widely-used Androxgh0st code but shares similarities with the Legion cloud infostealer in functionality and design.
  • Key features include credential harvesting for spamming attacks, AWS account hijacking tools, and functions to enable attacks against PayPal and various SaaS accounts.
  • FBot is characterized by a smaller footprint compared to similar tools, indicating possible private development and a more targeted distribution approach.

The cloud hacktool scene is highly intertwined, with many tools relying on one another’s code. This is particularly true for malware families like AlienFox , Greenbot, Legion, and Predator, which share code from a credential scraping module called Androxgh0st .

We identified a tool that is related but distinct from these families. FBot is a Python-based attack tool with features to target web servers and cloud services as well as Software-as-a-Service (SaaS) technologies, including:

  • Amazon Web Services (AWS)

FBot is unique in that it does not apparently adapt the Androxgh0st code so common among similar hacktools , though the earliest reference to FBot is one year more recent than the first sighting of Androxgh0st. However, there are several connections to the Legion cloud infostealer, making it likely the Legion maintainer adapted code from FBot into their tool.

FBot is primarily designed for actors to hijack cloud, SaaS, and web services. There is a secondary focus on obtaining accounts to conduct spamming attacks. Actors can use the credential harvesting features to obtain initial access, which they can sell to other parties.

The tool contains assorted utilities, including an IP address generator and port scanner. There is also an email validator function, which uses an Indonesian technology service provider to validate email addresses.

FBot menu and list of features

AWS Targeting

FBot has three functions dedicated to AWS account attacks. The first is an AWS API Key Generator, handled by function aws_generator , which generates a random AWS access key ID by appending 16 randomly selected alphabetic characters to the standard AKIA prefix. Then, it generates a secret key from 40 randomly selected alphabetic characters.

Despite FBot’s apparent lack of adopting the Androxgh0st modules, the same feature was highlighted in research on the Legion stealer as well as an older Androxgh0st variant, and it has not changed significantly. We agree with the aforementioned researchers’ conclusion that this feature is unlikely to succeed at brute forcing account credentials due to the possible number of access key and password combinations.

The second AWS feature is a Mass AWS Checker, handled by function aws_checker . This function checks for AWS Simple Email Service (SES) email configuration details, including the maximum send quota and rate, as well as how many messages have been sent in the past 24 hours, likely to maximize spamming efforts against the targeted account. It also creates a new user account with the username iDevXploit and the password MCDonald2021D#1337 and attaches the AdminsitratorAccess policy to elevate privileges for the new account. Unlike other cloud attack tools such as AlienFox, FBot does not delete the compromised account that the attacker used to gain access.

The third and final AWS feature is an AWS EC2 Checker, with the description Get EC2 VCPU Limit , which is handled by function ec_checker . This function reads a list of AWS identities from a text file in the format of AccessKey|SecretKey|Region . The script uses these values to check the targeted account’s EC2 service quotas. The FBot menu highlights that this can be used to check vCPU details, although the output is less straightforward. The query results describe the account’s EC2 configurations and capabilities, such as what types of EC2 instances can run. The script iterates through a list of specified AWS regions, runs the query again for each region, and logs the result to a text file.

Example EC2 quota output captured by FBot’s ec_checker function

SaaS & Payment Services Targeting

FBot has several features that target payment services as well as SaaS configurations.

The PayPal Validator feature is handled by paypal_validator . This function validates PayPal account status by contacting a hardcoded URL with an email address read from an input list. The email is added to the request in the customer details section to validate whether an email address is associated with a PayPal account.

The script initiates the Paypal API request via the website hxxps://www.robertkalinkin.com/index.php , which is a Lithuanian fashion designer’s retail sales website. Interestingly, all identified FBot samples use this website to authenticate the PayPal API requests, and several Legion Stealer samples do as well.

PayPal Validator crafts the request to this site with a fake item ID as well as phony customer details, then parses the response for a status message indicating success.

PayPal validation request data

FBot also targets several SaaS platforms, including Sendgrid and Twilio. The Sendgrid feature is a Sendgrid API Key Generator, which generates a Sendgrid key formatted like:

The Twilio feature takes the Twilio SID and Twilio Auth Token as input, separated by a pipe. The function then checks the SID & auth token combination for details about the account, including the balance and which currency, a list of phone numbers connected to the account.

Web Framework Features

FBot has features for validating if URLs host a Laravel environment file and for extracting credentials from those files. The Hidden Config Scanner feature takes a URL as input and crafts an HTTP GET request to several PHP, Laravel, and AWS-related URIs where configuration values may be stored, including:

The response is parsed for keys and secrets related to the following services and the result is written to a text file:

FBot also targets several popular Content Management Systems (CMS). The function cms_scanner contains a map of CMS and web frameworks to regular expressions (regex) associated with the service. The program creates a request to the targeted URL and parses the response for the following technologies:

FBot relies on configuration values to be fed to it through a configuration file (.ini), or through headers that initiate the main class. We identified one version that is compiled as a Windows executable.

The string iDevXploit is present across all samples: this handle is credited as the author in the main class. Additionally, the aws_checker function leaves artifacts in targeted AWS consoles: when FBot creates a new user in the AWS account, the username iDevXploit is consistent across samples, along with the password MCDonald2021D#1337 .

Unlike many similar cloud hacktools, FBot does not contain references to the open-source Androxgh0st code found in tools like AlienFox, GreenBot, and Predator . The logic implemented is very similar in that both Androxgh0st and FBot parse environment configuration files for credentials related to similar mail & cloud services, but the implementation is different and no code seems to be directly borrowed.

There is considerable overlap with the Legion cloud infostealer in how the tools scrape URLs for PHP configuration. However, FBot is much smaller and less fully featured than Legion, with FBot samples weighing in at approximately 200 KB and Legion ranging from 800-1200 KB in size.

FBot demonstrates another tool family that continues the trend of adopting cloud attack tool code from one tool into another, while maintaining its own distinct flavor. We have seen samples spanning July 2022 to January 2024, showing there is continued proliferation of this tool. However, there are relatively few changes across versions and it is unclear whether this is actively maintained.

As of this writing, we are unable to identify a distribution channel dedicated to FBot, which differentiates the tool from other cloud infostealers often sold on Telegram. The bot has references to buffer_0x0verfl0w, a Telegram channel associated with various crimeware that has since been retired. However, we found indications that FBot is the product of private development work, so contemporary builds may be distributed through a smaller scale operation. This aligns with the theme of cloud attack tools being bespoke ‘private bots’ tailored for the individual buyer, which is a theme prevalent among AlienFox builds.

Organizations should enable multi-factor authentication (MFA) for AWS services with programmatic access. Create alerts that notify security operations teams when a new AWS user account is added to the organization, as well as alerts for new identities added or major configuration changes to SaaS bulk mailing applications where possible.

Indicators of Compromise

specter attack

Alex Delamotte

Labscon replay | spectre strikes again: introducing the firmware edition, related posts, cloudy with a chance of credentials | aws-targeting cred stealer expands to azure, gcp, hypervisor ransomware | multiple threat actor groups hop on leaked babuk code to build esxi lockers, icefire ransomware returns | now targeting linux enterprise networks.

specter attack

Advertisement

Supported by

Attacks Heighten Fears of a Wider War for the Middle East and U.S.

The killing of a top Hamas leader in Lebanon and mysterious twin explosions in Iran heighten fears of a regional war that could draw in the United States.

  • Share full article

Emergency works carrying the body of a man to a vehicle.

By Eric Schmitt ,  Julian E. Barnes ,  Helene Cooper and David E. Sanger

Eric Schmitt, Julian E. Barnes, Helene Cooper and David E. Sanger have written extensively about Middle East wars and tensions between the United States and Iran.

American, Israeli and Lebanese officials insist that few parties want Israel’s war in Gaza to become a wider conflict that engulfs the Middle East.

But the assassination of a top leader of Hamas in Lebanon on Tuesday, and the deaths of scores of people in mysterious twin explosions in Iran on Wednesday, threatened to bring the Middle East — and the United States — closer to the brink of a regional war, which the Biden administration has tried to stave off since Hamas’s deadly attacks against Israel on Oct. 7.

Just hours after the bombs went off in Iran, the United States and 12 of its allies issued a written warning to another militia group in the region, the Houthis of Yemen, who have been mounting near-daily missile, drone and seaborne attacks on commercial vessels.

So far the United States has held back from retaliating against Houthi bases in Yemen, in large part because it does not want to undermine a fragile truce in Yemen’s civil war.

But now Biden officials are signaling that their patience is running out.

“Let our message now be clear: We call for the immediate end of these illegal attacks and release of unlawfully detained vessels and crews,” White House officials said in a statement issued on Wednesday, a day after the shipping giant Maersk announced it would pause operations in the Red Sea .

“The Houthis,” the statement continued, “will bear the responsibility of the consequences should they continue to threaten lives, the global economy, and free flow of commerce in the region’s critical waterways.”

The warning — also signed by Britain, Australia, New Zealand, Bahrain, Belgium, Canada, Germany, Denmark, Italy, Japan, Singapore and the Netherlands — stopped short of threatening military strikes. Over the weekend, the U.S. Navy sank three Houthi boats , killing all the crew members, when they fired on American helicopters coming to aid a Maersk cargo ship.

On Monday, Iran’s navy announced the deployment of a flotilla of warships to the waterway. On the same day, Foreign Minister Hossein Amir-Abdollahian of Iran expressed “gratitude and appreciation” to a Houthi official visiting Tehran for the group’s support for Hamas, the government-run IRNA news agency reported.

A senior Iranian official said dispatching the warships, which join an Iranian spy ship already in the region, was meant to signal that Iran is supporting the Houthis and to raise the stakes. But the official said Iran has no plans for the warships to engage in a confrontation with U.S. naval vessels in the waterway.

President Biden has said he wants to avoid direct military attacks on the Houthis to avoid escalating a Middle East conflict.

“We remain incredibly concerned, as we have been from the outset of this conflict, about the risk of the conflict spreading into other fronts,” Matthew Miller, a State Department spokesman, told reporters on Wednesday.

Hezbollah, the powerful Lebanese militant group, has pledged that Tuesday’s killing of Saleh al-Arouri, the Hamas leader, in a Beirut suburb, would not pass without a response. A key ally to Hamas, Hezbollah exercises de facto control over Beirut’s southern suburbs where the explosion occurred and has been engaged in escalating clashes with Israeli forces for months.

The circumstances surrounding the blasts at a memorial for Iran’s former general, Qassim Suleimani , in Kerman, Iran, were murkier. While Iran was quick to blame Israel, European and American officials said they doubted that the Israelis conducted the strike: Most of their actions against Iran have been highly targeted, from taking out the chief architect of Iran’s nuclear program to blowing up specific nuclear and missile facilities.

Three senior American officials and one senior European official said on Wednesday that the Islamic State or another terrorist group was a possible perpetrator. While there is some intelligence that points to Islamic State involvement in the attack, the officials cautioned the assessment is preliminary and no final conclusions have been drawn.

“It is entirely possible that one of the Israeli proxy groups let an attack get out of hand,” Ray Takeyh, a senior fellow at the Council on Foreign Relations who writes often about Iran, said on Wednesday.

Ayatollah Ali Khamenei, Iran’s supreme leader, issued a statement on Wednesday blaming the attack on the nation’s “malicious and criminal enemies,” but stopped short of naming any group or country. Mr. Khamenei vowed that Iran’s enemies should know that “this tragedy will have a strong response.”

Two people familiar with Iran’s internal discussions said that the ayatollah had instructed Iranian military commanders to pursue “strategic patience” and avoid getting Iran into a direct military confrontation with the United States.

Video player loading

Several American officials said it was too soon to predict whether any kind of wider war would erupt. Israel, the officials said, would not have struck Mr. al-Arouri without some belief that they could do so without escalating the conflict on the Lebanon border. But with the explosions, whatever the cause, coming so quickly after the assassination, there was little doubt that the risk of a spreading conflict was once more front of mind in the United States and Europe.

Israeli officials would not comment on whether their forces had targeted Mr. al-Arouri, but Lebanese and American officials ascribed the attack to Israel.

In the wake of the strike, Biden administration officials made plans to step up diplomatic efforts with officials in Lebanon as part of an effort to pressure Hezbollah not to escalate the conflict. In coming days, Secretary of State Antony J. Blinken is expected to travel to the Middle East, where containing potential escalation will be one of his foremost goals.

“The chances of a regional war in the Middle East go up from 15 percent to as high as 30 percent,” said retired Adm. James Stavridis, the former NATO commander. “Still relatively low, but higher than before, and certainly uncomfortably high.”

But Biden administration officials and Middle East analysts noted that while Hezbollah and Iran have engaged in skirmishes and proxy attacks against Israel, they are not necessarily eager to widen the conflict.

“Throughout the devastation in Gaza, Hezbollah has maintained that they will engage in a limited way” to tie up some of Israel’s forces near Lebanon, Paul Salem, the president of the Middle East Institute, said in an interview. “It’s been crystal clear that they are not joining the fight directly.”

He and other analysts said that while Iran has helped plan and orchestrate some of the attacks taking place in the Middle East — including the Houthi’s missile attacks on shipping in the Red Sea — it has not taken on the United States or Israel directly.

Mr. Biden and his top aides have sought since the Oct. 7 attacks to contain the conflict between Israel and Hamas to the Gaza Strip. The Pentagon dispatched two aircraft carriers and doubled the number of American warplanes to the Middle East to deter Iran and its proxies in Lebanon, Yemen, Syria and Iraq from widening the war. Now that strategy is fraying. One of those carrier groups, led by the Gerald R. Ford, is leaving the area , the Pentagon said this week.

Iran-backed militias have attacked U.S. troops stationed in Iraq and Syria for counterterrorism duties 118 times since the Oct. 7 attacks, most recently on Monday. Several U.S. service members have been injured in the strikes, at least one critically, prompting the Pentagon to retaliate five times with airstrikes against the groups.

In recent weeks, the Biden administration declassified intelligence indicating that Iranian paramilitary groups were coordinating the Houthi attacks, providing targeting information about commercial shipping passing through the waterway and the Suez Canal. Israel is heavily dependent on Red Sea shipping traffic.

In response to the attacks, the United States has created a multinational naval task force to protect commercial ships in both the Red Sea and the Gulf of Aden.

Pentagon officials have worked up detailed plans for striking missile and drone bases in Yemen, and some of the facilities where fast boats of the kind used to attack the Maersk container ship appear to be tied up. But there is concern that such strikes would play into Iran’s strategy to bog down Israel and its allies on multiple fronts.

But the most serious threat to containing the Gaza conflict burst onto the scene Tuesday with the assassination of Mr. al-Arouri .

“The loss of someone so intimately involved in both tactical operations and strategic diplomacy is a serious setback for Hamas,” Hanin Ghaddar and Matthew Levitt wrote in an analysis for the Washington Institute for Near East Policy. “What remains to be seen is how the group’s allies, especially Hezbollah, react to the attack.”

Western leaders sought to tamp down the fast-rising tensions. President Emmanuel Macron of France said shortly after the strike that it was “essential to avoid any escalatory attitude, particularly in Lebanon.”

In a phone call with Benny Gantz, an opponent of Prime Minister Benjamin Netanyahu of Israel who has joined the country’s wartime unity government, Mr. Macron said that “France would continue to pass on these messages to all players directly or indirectly involved in the area,” according to a summary of the call from the French presidency.

Farnaz Fassihi contributed reporting from New York, and Michael Crowley from Washington.

An earlier version of this article misstated the number of countries that jointly issued a written warning to the Houthi militia group against further attacks on ships. The United States was joined by 12 of its allies, not 11.

How we handle corrections

Eric Schmitt is a national security correspondent for The Times, focusing on U.S. military affairs and counterterrorism issues overseas, topics he has reported on for more than three decades. More about Eric Schmitt

Julian E. Barnes covers the U.S. intelligence agencies and international security matters for The Times. He has written about security issues for more than two decades. More about Julian E. Barnes

Helene Cooper is a Pentagon correspondent. She was previously an editor, diplomatic correspondent and White House correspondent. More about Helene Cooper

David E. Sanger covers the Biden administration and national security. He has been a Times journalist for more than four decades and has written several books on challenges to American national security. More about David E. Sanger

Ecuador city tries to return to normal after gang horror

  • Published 6 days ago

Soldiers patrol outside the broadcast channel targeted by gangs earlier this week

Gradually, and with trepidation, life in Guayaquil is beginning to return.

Few residents have fully recovered from the shock - from the outright chaos and bloodshed - of this week, a moment which will live long in the city's collective memory.

But Dina Moreno can't afford to stay home any longer. She sells mobile phone accessories at Guayaquil's biggest covered market and, like many of her fellow stallholders, has ventured out to open her business and get back to work.

"I've never seen anything like it," she recalls with a shudder. "When we saw what was happening at the TV station and we heard gunshots, everyone went crazy and started shutting up their shops and trying to get home."

Behind her, as she talks, Dina's seven-year-old son plays with some mobile phone covers. Schools in the city remain closed after the explosion of gang violence. Such was her loss of income from two days with no sales, Dina had no choice but to bring him to work.

Dina and her son at the phone stall

It's a similar story elsewhere in the sprawling market, as street food vendors, delivery boys and a preacher reciting Bible verses bring back the noise and bustle which has been absent since the attack.

The spectre of the drug-gang violence remains, though. One vendor, Jorge, told me that the stall owners were all watching out for each other under the market's huge white awnings, keeping an eye out for the first sign of more trouble or the return of armed men to the streets.

"I'm not scared of death," he says, without a hint of bravado. "I just want to see peace return to my Ecuador."

But while the small businesses of Guayaquil may be trying to get back to some form of normality, it's far from business as usual for Andres. His brother is among the 178 prison staff - most of them guards - still being held hostage by the gangs.

"The only information we've had is from the guards who managed to get out. They're the only ones who have told us that our relatives are OK," he tells me from outside the Ambato prison, where he's spent hours waiting for news.

The police will only tell the desperate family members that they're waiting for orders to enter the prison. Andres says they haven't seen any movement from them in days.

He adds that the guards had warned that something bad was going to happen in the prison, but the authorities didn't listen.

The government insists that the country is now engaged in a war with the gangs and cannot back down in the face of intimidation, from either inside or outside the prisons. "Hostage-taking is the ugly part of war," President Daniel Noboa said this week.

That is of little comfort to Andres though, who accuses the government of negligence and of forgetting about his brother.

"I just hope they're not going to treat them as cannon-fodder," he says.

Amid the chaos, the most brazen act of gang violence was in the TC television studio in Guayaquil when armed men took staff hostage, brandishing weapons at the journalists live on air.

This video can not be played

To play this video you need to enable JavaScript in your browser.

Watch: Armed men interrupt live broadcast and threaten presenter (contains distressing scenes)

In the ensuing ordeal, presenter Jose Luis Calderon could be seen urging the gang members to stay calm, even while they pointed a shotgun at his head and placed a stick of dynamite in his breast-pocket.

"I felt strangely calm even though I knew our lives were at risk," he recalls when we met him afterwards. Jose Luis described how he hid in a bathroom with a several colleagues when they heard yelling and gunfire. But their hiding place was soon discovered, and they were hauled out to join the other staff on set, at gunpoint.

"They sent kids, armed to the teeth, to spread fear, uncertainty, anxiety and chaos," he says. "They were there to send the message that they can just walk in and take over one of the biggest media outlets in the country."

Hundreds of gang members have now been detained by the police. While the streets of Guayaquil are empty during the night-time curfew, by day they're getting busier as people come and go about their normal business.

As the days pass from the most terrifying experience in its modern history, it is beginning to look like Ecuador is returning to normality.

The risk is that it is actually hurtling towards an entrenched armed conflict, and moving ever closer to becoming a full "narco-state".

Related Topics

More on this story.

How Ecuador descended into gang violence

  • Published 10 January

Soldiers in an armoured vehicle patrol the city's historic centre following an outbreak of violence a day after Ecuador's President Daniel Noboa declared a 60-day state of emergency following the disappearance of Adolfo Macias, leader of the Los Choneros criminal gang from the prison where he was serving a 34-year sentence, in Quito, Ecuador, January 9, 2024.

Ecuador president defies gangs to take on the army

Soldiers stand guard outside the presidential palace following a wave of violence around the nation, prompting President Daniel Noboa to declare gangs to be terrorist organisations to be hunted by the military, in Quito, Ecuador January 10, 2024.

comscore

Israel attacks Hizbullah target in Lebanon close to border

Army mounts strike with warplanes and artillery on strategic islamist compound inside neighbouring country.

specter attack

An Israeli artillery unit fires across the border towards Lebanon earlier this week: The exchanges have killed 150 Hizbullah fighters and 27 Lebanese civilians, 12 Israeli troops and six Israeli civilians. According to the UN, 82,000 Lebanese have fled their homes. Photograph: Amir Levy/Getty

The Israeli army announced on Tuesday that it had mounted an attack with warplanes and artillery on a strategic Hizbullah compound in Lebanon, near the Israeli border. The attack came a day after UN secretary general António Guterres warned Lebanon and Israel against escalating cross-border strikes which could, by design or accident, lead to full-scale war. He said: “We cannot see in Lebanon what we are seeing in Gaza.”

Daily exchanges of missiles and drones began after the October 7th raid into Israel by Hamas fighters who, the Israeli daily Haaretz reported, killed 1,151 people and abducted 240.

Israel has recently escalated hostilities by mounting air raids deep into Lebanon, while Hizbullah has fired tank rounds at Israeli military posts and settlements. Last month, Israeli prime minister Binyamin Netanyahu warned that Beirut and southern Lebanon would be turned into Gaza if war erupts.

Mr Guterres told Hizbullah and the Israeli army to “de-escalate and bring hostilities to an end in accordance with Security Council Resolution 1701″. This resolution, which halted the 2006 war, calls for the Lebanese army to deploy along a UN delineated Blue Line border and the creation of a buffer zone north of the border. Last week, a ceasefire and an implementation of Resolution 1701 was discussed by Israeli-born US mediator Amos Hochstein, Lebanese prime minister Najib Mikati and parliamentary speaker Nabih Berri.

US military fires fresh barrage of missiles at Houthi sites in Yemen

US military fires fresh barrage of missiles at Houthi sites in Yemen

Global leaders at World Economic Forum confronted by rising Middle East tensions

Global leaders at World Economic Forum confronted by rising Middle East tensions

Israel presses assault in southern Gaza as Jordan says field hospital badly damaged

Israel presses assault in southern Gaza as Jordan says field hospital badly damaged

US expected to relist Yemen’s Houthis as ‘specially designated global terrorists’

US expected to relist Yemen’s Houthis as ‘specially designated global terrorists’

[  Israeli strike on Lebanon kills senior Hizbullah commander as fighting continues in Gaza  ]

[  Israel-Hamas War: More troops moved out of Gaza as protesters call on Netanyahu to resign over hostages  ]

The exchanges have killed 150 Hizbullah fighters and 27 Lebanese civilians, 12 Israeli troops and six Israeli civilians. According to the UN, 82,000 Lebanese have fled their homes in 91 southern villages. Dozens of buildings have been destroyed. L’Orient Today said 81 per cent of displaced people are hosted by families, while 16 per cent are in rented flats.

While Israel says 96,000 Israelis have left northern towns and kibbutzim to be housed out of range by the government in hotels, the impact of the exchanges has been far greater for Lebanon which, since 2019, has suffered its worst economic and political crisis.

Lebanon’s economy ministry reported that the fertile south, which produces 22 per cent of the country’s fruit and 38 per cent of its olives, has been hit hard. Agriculture contributes 80 per cent to the gross domestic product of the south. Nearly 50,000 olive trees have been burnt and grains and winter crops have diminished, while 1.4 million of 5.6 million residents are food-insecure.

[  Israel-Hamas conflict enters 100th day as Netanyahu says ‘no one will stop’ Israel  ]

[  Israel-Hamas war: Dozens of Palestinians killed in northern Gaza, Israeli army says  ]

According to the Washington-based Tahrir Institute for Middle East policy, the conflict “marks the first time agricultural areas in Lebanon have been this openly and extensively targeted” with white phosphorus bombs which cause “serious environmental and economic damage”.

Lebanon’s National Early Warning System estimated that 800 hectares have been destroyed by fire caused by Israeli attacks.

Israeli munitions have produced an increase in air, water and soil pollution. “The toxic compounds from explosive weapons, with white phosphorus usage, further reduces fertility [of farmland] and increases soil acidity,” the UN reported.

  • Sign up for push alerts and have the best news, analysis and comment delivered directly to your phone
  • Find The Irish Times on WhatsApp and stay up to date
  • Our In The News podcast is now published daily – Find the latest episode here

Michael Jansen

Michael Jansen

Michael Jansen contributes news from and analysis of the Middle East to The Irish Times

IN THIS SECTION

Pakistan carries out missile strikes on militants in iran, iran claims missile strike on pakistan that killed two children was aimed at ‘terrorists’, court blocks attempts by drew harris to dismiss garda who had sexual encounter with ‘vulnerable’ woman in station, provisional liquidators appointed to prepaid card issuer, all special needs students ‘should be educated in mainstream schools’, council recommends, fintan o’toole: dup’s crush on britain will end badly, nigerian man who feared he would be killed over failure to join cult has asylum application rejection upheld, latest stories, snow showers, frost and ice predicted by met éireann, mcgrath warns over sinn féin’s tax policies, hitting housing targets and a mac love affair, ‘the things some married pilots say to get you into bed’.

  • Terms & Conditions
  • Privacy Policy
  • Cookie Information
  • Cookie Settings
  • Community Standards

IMAGES

  1. True Ghost Story

    specter attack

  2. Researchers Revealed New Spectre-Class Attack

    specter attack

  3. Specter attack generation Hypervisor Attack (DoS) An attempt to take

    specter attack

  4. How to defeat Specters in Horizon Forbidden West

    specter attack

  5. Specter attack generation Hypervisor Attack (DoS) An attempt to take

    specter attack

  6. Spectre Is Back: Side-Channel Attacks On AMD Ryzen And Intel Core Is

    specter attack

VIDEO

  1. Spectre

  2. Spectre

  3. The Spectre

  4. Spectre

  5. spectre

  6. meet specter!

COMMENTS

  1. Spectre (security vulnerability)

    Spectre is one of the two original transient execution CPU vulnerabilities (the other being Meltdown ), which involve microarchitectural timing side-channel attacks. These affect modern microprocessors that perform branch prediction and other forms of speculation.

  2. Meltdown and Spectre

    arXiv Spectre Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre

  3. Spectre and Meltdown explained: A comprehensive guide ...

    Spectre and Meltdown are uniquely dangerous security vulnerabilities that allow malicious actors to bypass system security protections present in nearly every recent device with a CPU-not just...

  4. What is Meltdown/Spectre?

    What is Meltdown/Spectre? Meltdown and Spectre are recently-discovered vulnerabilities found in Intel, AMD, Apple, and ARM processor chips.

  5. Meltdown (security vulnerability)

    From Wikipedia, the free encyclopedia Transient execution CPU vulnerability IBM POWER processors Meltdown is one of the two original transient execution CPU vulnerabilities (the other being Spectre ). Meltdown affects Intel x86 microprocessors, IBM POWER processors, [1] and some ARM-based microprocessors.

  6. Spectre and Meltdown explained: What they are, how they work, what's at

    Spectre and Meltdown are the names given to different variants of the same fundamental underlying vulnerability that affects nearly every computer chip manufactured in the last 20 years and...

  7. New Spectre attack once again sends Intel and AMD scrambling for a fix

    154 Since 2018, an almost endless series of attacks broadly known as Spectre has kept Intel and AMD scrambling to develop defenses to mitigate vulnerabilities that allow malware to pluck...

  8. PDF Spectre Attacks: Exploiting Speculative Execution

    Spectre Attacks: Exploiting Speculative Execution Paul Kocher1, Jann Horn2, Anders Fogh3, Daniel Genkin4, Daniel Gruss5, Werner Haas6, Mike Hamburg7, Moritz Lipp5, Stefan Mangard5, Thomas Prescher6, Michael Schwarz5, Yuval Yarom8 1Independent(www.paulkocher.com),2Google Project Zero,

  9. How Meltdown and Spectre Were Independently Discovered By Four Research

    The vulnerabilities behind the devastating Meltdown and Spectre attacks have existed for decades. Four groups of researchers independently found them within mere months of each other....

  10. Answering your questions about "Meltdown" and "Spectre"

    Independent researchers separately discovered and named these vulnerabilities "Spectre" and "Meltdown.". Project Zero described three variants of this new class of speculative execution attack. Variant 1 and Variant 2 have been referred to as "Spectre.". Variant 3 has been referred to as "Meltdown.".

  11. Spectre Attacks: Exploiting Speculative Execution

    Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary.

  12. PDF Spectre Attacks: Exploiting Speculative Execution

    others. The Spectre family of attacks is documented un-der CVE-2017-5753and CVE-2017-5715. 1.4 Meltdown Meltdown [27] is a related microarchitectural attack which exploits out-of-order execution in order to leak the target's physical memory. Meltdown is distinct from Spectre Attacks in two main ways. First, unlike Spectre,

  13. Spectre attacks against websites still a serious threat, Google warns

    The PoC is based on a gadget that exploits the "variant 1" Spectre vulnerability across a side-channel that observes the side-effect of the attack. Variant 1 Spectre, also known as the "bounds check bypass attack", manipulates the speculative execution mechanisms of processors to access out-of-bounds memory locations.

  14. How the Spectre and Meltdown Hacks Really Worked

    These types of attacks, called Meltdown and Spectre, were no ordinary bugs. At the time it was discovered, Meltdown could hack all Intel x 86 microprocessors and IBM Power processors, as well as some ARM-based processors. Spectre and its many variations added Advanced Micro Devices ( AMD) processors to that list.

  15. Spectre Explained

    225 5.2K views 2 years ago Spectre is a side-channel attack that leverage speculative execution to get sensitive information stored in the CPU, intel back in 2018 struggling with this attack...

  16. Spectre attacks come back from the dead

    Spectre-based attacks trick a program into accessing arbitrary locations in a program's memory space. As a result an attacker may be able to read the content of the accessed memory, and thus potentially obtain sensitive data. Or, as the researchers put it: A Spectre attack tricks the processor into executing instructions along the wrong path.

  17. PDF Spectre Attacks: Exploiting Speculative Execution

    Spectre Attacks: Exploiting Speculative Execution Paul Kocher1, Jann Horn2, Anders Fogh3, Daniel Genkin4, Daniel Gruss5, Werner Haas6, Mike Hamburg7, Mortiz Lipp5, Stefan Mangard5, Thomas Prescher6, Michael Schwartz5, Yuval Yarom8 1 Independent, 2 Google Project Zero, 3 G DATA Advanced Analytics, 4 University of Pennsylvania and University of

  18. Spectre vulnerability: 4 years after discovery

    February 1, 2022. Four years have passed since the first publication of the research on Spectre and Meltdown, hardware vulnerabilities in modern processors. Since then, researchers discovered several similar flaws, that are potentially capable of leaking confidential data. The researchers also showed examples of attacks using these ...

  19. 5 Ways to Prevent a Spectre or Meltdown Attack

    To defend against Spectre and Meltdown, MacDonald recommends security leaders take the following steps: Create a detailed inventory: Nearly every modern IT system will be affected to some extent. The starting point for security leaders must be to inventory all affected systems. Develop and prioritize remediation efforts: The vulnerabilities are ...

  20. Spectre Attacks: Exploiting Speculative Execution

    Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary.

  21. Spectre Security Vulnerability

    Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side-channel to the adversary. This also exposes otherwise protected memory space, allowing the malicious agent to access the data, or even modify it.

  22. Spectre attacks: exploiting speculative execution

    Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side-channel attacks, fault attacks, and return ...

  23. A Flaw in Millions of Apple, AMD, and Qualcomm GPUs Could ...

    The attack program the researchers created uses less than 10 lines of code. An attacker ... In the six years since disclosure of the Spectre and Meltdown CPU processor vulnerabilities, chipmakers ...

  24. U.N. Warns Gaza Is Heading for Famine as Specter of Wider War Looms

    The solitary strike came about 24 hours after a much wider barrage of U.S.-led strikes against nearly 30 sites in northern and western Yemen that were intended to deter Houthi attacks on ...

  25. US attacks in Yemen sharpen Biden's military and political ...

    US and British airstrikes against Iran-backed militants in Yemen represent a significant escalation of the conflict in the Middle East - and come despite weeks of efforts by President Joe Biden ...

  26. Python-Based Malware Targeting Cloud and Payment Services

    Executive Summary. FBot is a Python-based hacking tool distinct from other cloud malware families, targeting web servers, cloud services, and SaaS platforms like AWS, Office365, PayPal, Sendgrid, and Twilio. FBot does not utilize the widely-used Androxgh0st code but shares similarities with the Legion cloud infostealer in functionality and design.

  27. Attacks Heighten Fears of a Wider War for the Middle East and U.S

    A damaged vehicle near the site of an explosion that killed Saleh al-Arouri, a senior Hamas leader, in Beirut on Wednesday. EPA, via Shutterstock. Iran-backed militias have attacked U.S. troops ...

  28. Ecuador city tries to return to normal after gang horror

    Life is returning to the streets of Guayaquil but the spectre of drug-gang violence remains. ... bring back the noise and bustle which has been absent since the attack. The spectre of the drug ...

  29. Israel attacks Hizbullah target in Lebanon close to border

    Tue Jan 16 2024 - 18:20. The Israeli army announced on Tuesday that it had mounted an attack with warplanes and artillery on a strategic Hizbullah compound in Lebanon, near the Israeli border. The ...