Microsoft has acknowledged the existence of a severe and currently unpatched vulnerability in Windows' Print Spooler service (CVE-2021-34527). The vulnerability affects all versions of Windows, and is being actively exploited as per Microsoft. Poetically named "PrintNightmare", the vulnerability was published earlier this week as a PoC (Proof of Concept) exploit by security researchers, which believed the flaw had already been addressed by Microsoft at time of release (the company patched up another Print Spooler vulnerability issue with the June 2021 security patch). The code was made public and quickly scrapped when developers realized it gave would-be bad actors access to an unpatched way into users' systems - but since it's the Internet, the code had already been forked in GitHub.

The vulnerability isn't rated by the Windows developer as of yet, but it's one of the bad ones: it allows attackers to remotely execute code with system-level privileges. This is the ultimate level of security vulnerability that could exist. Microsoft is currently investigating the issue and developing a patch; however, given the urgency in closing down this exploit, the company is recommending disabling of the Windows Print Spooler service wherever possible, or at least disabling inbound remote printing through Group Policy. If you don't have a printer, just disable the service; if you do, please disable the Group Policy as per the steps outlined in the image below.

Dell notebooks and desktops dating all the way back since 2009—hundreds of millions of them the PC giant has shipped since—are vulnerable to unauthorized privilege escalation attacks, due to a faulty OEM driver the company uses to update the computer's BIOS or UEFI firmware, according to findings by cybersecurity researchers at SentinelLabs. "DBUtil," a driver that Dell machines load during automated or unattended BIOS/UEFI update processes initiated by the user from within the OS, is found to have vulnerabilities that malware can exploit to "escalate privileges from a non-administrator user to kernel mode privileges."

SentinelLabs chronicled its findings in CVE-2021-21551, which details five individual flaws. Two of these point out flaws that can escalate user privileges through controlled memory corruption, two with lack of input validation; and one with denial of service. Organizations that have remote updates enabled for their client machines are at risk, since the flaw can be exploited over network. "An attacker with access to an organization's network may also gain access to execute code on unpatched Dell systems and use this vulnerability to gain local elevation of privilege. Attackers can then leverage other techniques to pivot to the broader network, like lateral movement," writes SentielLabs in its paper.

Researches from the University of Virginia and University of California San Diego have published their latest case study. The two universities have worked hard to discover a new Spectre vulnerability variant that can pass all of the existing Spectre mitigations and exploit all of the existing processors coming from Intel and AMD. The vulnerability exploits all of the existing x86 processors, and as it is new, there are not implementations of hardware mitigation. The whitepaper called "I see dead μops" takes the implementation of exploiting micro-op caches that could lead to a potential data leak in the processor, which is leading to a Spectre-type exploit.

Modern x86 processors break down complex instructions into smaller RISC-like units called micro-ops, in the frontend, where it makes the design of the backend part much simpler. The micro-ops are stored in the micro-ops cache. The paper is describing micro-op cache-based timing channel exploits in three primary settings: "a) across code regions within the same thread, but operating at different privilege levels, (b) across different co-located threads running simultaneously on different SMT contexts (logical cores) within the same physical core, and (c) two transient execution attack variants that leverage the micro-op cache to leak transiently accessed secrets, bypassing several existing hardware and software-based mitigations, including Intel's recommended LFENCE."

AMD Ryzen 5000 series of processors feature the new Zen 3 core design, which uses many techniques to deliver the best possible performance. One of those techniques is called Predictive Store Forwarding (PSF). According to AMD, "PSF is a hardware-based micro-architectural optimization designed to improve the performance of code execution by predicting dependencies between loads and stores." That means that PSF is another "prediction" feature put in a microprocessor that could be exploited. Just like Spectre, the feature could be exploited and it could result in a vulnerability in the new processors. Speculative execution has been a part of much bigger problems in CPU microarchitecture design, showing that each design choice has its flaws.

AMD's CPU architects have discovered that the software that relies upon isolation aka "sandboxing", is highly at risk. PSF predictions can sometimes miss, and it is exactly these applications that are at risk. It is reported that a mispredicted dependency between load and store can lead to a vulnerability similar to Spectre v4. So what a solution to it would be? You could simply turn it off and be safe. Phoronix conducted a suite of tests on Linux and concluded that turning the feature off is taking between half a percent to one percent hit, which is very low. You can see more of that testing here, and read AMD's whitepaper describing PSF.

Acer has reportedly been hit with a REvil ransomware attack covering financial spreadsheets, bank balances, and bank communications. The actors are demanding a 50 million USD ransom which is one of the highest amounts ever demanded in a breach of this type. Acer has not confirmed the report instead stating that they "reported recent abnormal situations" to the relevant authorities. Communication between REvil and Acer began on March 14th with the attackers demanding payment in XMR cryptocurrency via a Tor website in return for the decryptor, a vulnerability report, and the deletion of stolen files. The cause of the attack appears to be a vulnerability in Microsoft Exchange which has now been patched but was not updated by Acer. The group is demanding payment before March 28th or the price will double to 100 million USD.

Discovering vulnerabilities in software is not an easy thing to do. There are many use cases and states that need to be tested to see a possible vulnerability. Still, security researchers know how to find those and they usually report it to the company that made the software. Today, AMD has disclosed that there is a vulnerability present in the company graphics driver powering the GPUs and making them work on systems. Called CreateAllocation (CVE-2020-12911), the vulnerability is marked with a score of 7.1 in the CVSSv3 test results, meaning that it is not a top priority, however, it still represents a big problem.

"A denial-of-service vulnerability exists in the D3DKMTCreateAllocation handler functionality of AMD ATIKMDAG.SYS 26.20.15029.27017. A specially crafted D3DKMTCreateAllocation API request can cause an out-of-bounds read and denial of service (BSOD). This vulnerability can be triggered from a guest account, " says the report about the vulnerability. AMD states that a temporary fix is implemented by simply restarting your computer if a BSOD happens. The company also declares that "confidential information and long-term system functionality are not impacted". AMD plans to release a fix for this software problem sometime in 2021 with the new driver release. You can read more about it here.

Vulnerabilities in Qualcomm's DSP (Digital Signal Processor) present in the company's Snapdragon SoCs may render more than a billion Android phones susceptible to hacking. According to research reported this week by security firm Check Point, they've found more than 400 vulnerabilities in Snapdragon's DSP, which may allow attackers to monitor locations, listen to nearby audio in real time, and exfiltrate locally-stored photos and videos - besides being able to render the phone completely unresponsive.

The vulnerabilities (CVE-2020-11201, CVE-2020-11202, CVE-2020-11206, CVE-2020-11207, CVE-2020-11208 and CVE-2020-11209) can be exploited simply via a video download or any other content that's rendered by the chip that passes through its DSP. Targets can also be attacked by installing malicious apps that require no permissions at all. Qualcomm has already tackled the issue by stating they have worked to validate the issue, and have already issued mitigations to OEMs, which should be made available via software updates in the future. In the meantime, the company has said they have no evidence any of these flaws is being currently exploited, and advise all Snapdragon platform users to only install apps via trusted locations such as the Play Store.

Even if you don't have more than one operating system installed, your PC has a boot-loader, a software component first executed by the system BIOS, which decides which operating system to boot with. This also lets users toggle between different run-levels or configurations of the same OS. The GRUB2 boot-loader is deployed across billions of computers, servers, and pretty much any device that uses a Unix-like operating system. Cybersecurity researchers with Oregon-based firm Eclypsium, discovered a critical vulnerability with GRUB2 that can compromise a device's operating system. They named the vulnerability BootHole. This is the same firm behind last year's discovery of the Screwed Drivers vulnerability. It affects any device that uses the GRUB2 boot-loader, including when combined with Secure Boot technology.

BootHole exploits a design flaw with two of the key components of GRUB2, bison, a parser generator, and flex, a lexical analyzer. Eclypsium discovered that these two can have "mismatched design assumptions" that can lead to buffer overflow. This buffer overflow can be exploited to execute arbitrary code. Devices with modern UEFI and Secure Boot enabled typically wall off even administrative privileged users off from tampering with boot processes, however, in case of BootHole, the boot-loader parses a configuration file located in the EFI partition of the boot device, which can be modified by any user (or malicious process) that has admin privileges. Thankfully, patched versions of GRUB2 are already out, and the likes of SUSE have started distributing it for all versions of SUSE Linux. Expect practically every other *nix vendor, server manufacturer, to release patches to their end-users. Find a technical run-down of the vulnerability in this PDF by Eclypsium.

AMD on Wednesday disclosed a new security vulnerability affecting certain client- and APU processors launched between 2016 and 2019. Called the SMM Callout Privilege Escalation Vulnerability, discovered by Danny Odler, and chronicled under CVE-2020-12890, the vulnerability involves an attacker with elevated system privileges to manipulate the AGESA microcode encapsulated in the platform's UEFI firmware to execute arbitrary code undetected by the operating system. AMD plans to release AGESA updates that mitigate the vulnerability (at no apparent performance impact), to motherboard vendors and OEMs by the end of June 2020. Some of the latest platforms are already immune to the vulnerability.A statement by AMD follows.

Intel has had quite a lot of work trying to patch all vulnerabilities discovered in the past two years. Starting from Spectre and Meltdown which exploited speculative execution of the processor to execute malicious code. The entire process of speculative execution relies on the microarchitectural technique for adding more performance called speculative branch prediction. This technique predicts branch paths and prepared them for execution, so the processor spends less time figuring out where and how will instructions flow through the CPU. So far, lots of these bugs have been ironed out with software, but a lot of older CPUs are vulnerable.

However, an attacker has always thought about doing malicious code execution on a CPU core shared with the victim, and never on multiple cores. This is where the new CrossTalk vulnerability comes in. Dubbed Special Register Buffer Data Sampling (SRBDS) by Intel, it is labeled as CVE-2020-0543 in the vulnerability identifier system. The CrossTalk is bypassing all intra-core patches against Spectre and Meltdown so it can attack any CPU core on the processor. It enables attacker-controlled code execution on one CPU core to leak sensitive data from victim software executing on a different core. This technique is quite dangerous for users of shared systems like in the cloud. Often, one instance is shared across multiple customers and until now they were safe from each other. The vulnerability uses Intel's SGX security enclave against the processor so it can be executed. To read about CrossTalk in detail, please visit the page here.

Nowadays wireless technologies are increasingly sharing spectrum. This is the case for Wi-Fi and Bluetooth, but also some LTE bands and harmonics. Operating on the same frequency means that these different technologies need to coordinate wireless spectrum access to avoid collisions. Especially for nearby sources, as it is the case for multiple chips within one smartphone, so-called coexistence is the key to high-performance spectrum sharing.

Coexistence between wireless chips can be implemented in various ways. While there are open specifications, most manufacturers opt to develop proprietary coexistence mechanisms to further improve performance. Open interfaces are not needed on combo chips that implement multiple wireless technologies, as the manufacturer has full control.

Spectra, a new vulnerability class, relies on the fact that transmissions happen in the same spectrum and wireless chips need to arbitrate the channel access. While coexistence should only increase performance, it also poses a powerful side channel.

Dutch researcher from the Eindhoven University of Technology has found a new vulnerability in Thunderbolt port that allows attackers with physical access to unlock any PC running Windows or Linux kernel-based OS in less than 5 minutes. The researcher of the university called Björn Ruytenberg found a method which he calls Thunderspy, which can bypass the login screen of any PC. This attack requires physical access to the device, which is, of course, dangerous on its own if left with a person of knowledge. The Thunderbolt port is a fast protocol, and part of the reason why it is so fast is that it partially allows direct access to computer memory. And anything that can access memory directly is a potential vulnerability.

The Thunderspy attack relies on just that. There is a feature built into the Thunderbolt firmware called "Security Level", which disallows access to untrusted devices or even turns off Thunderbolt port altogether. This feature would make the port be a simple USB or display output. However, the researcher has found a way to alter the firmware setting of Thunderbolt control chip in a way so it allows any device to access the PC. This procedure is done without any trace and OS can not detect that there was a change. From there, the magic happens. Using an SPI (Serial Peripheral Interface) programmer with a SOP8 clip that connects the pins of the programmer device to the controller, the attacker just runs a script from there. This procedure requires around $400 worth of hardware. Intel already put some protection last year for the Thunderbolt port called Kernel Direct Memory Access Protection, but that feature isn't implemented on PCs manufactured before 2019. And even starting from 2019, not all PC manufacturers implement the feature, so there is a wide group of devices vulnerable to this unfixable attack.

Researchers have found another vulnerability Inside Intel's Converged Security and Management Engine (CSME). For starters, the CSME is a tiny CPU within a CPU that has access to whole data throughput and is dedicated to the security of the whole SoC. The CSME system is a kind of a black box, given that Intel is protecting its documentation so it can stop its copying by other vendors, however, researchers have discovered a flaw in the design of CSME and are now able to exploit millions of systems based on Intel CPUs manufactured in the last five years.

Discovered by Positive Technologies, the flaw is lying inside the Read-Only Memory (ROM) of the CSME. Given that the Mask ROM is hardcoded in the CPU, the exploit can not be fixed by a simple firmware update. The researchers from Positive Technologies describe it as such: "Unfortunately, no security system is perfect. Like all security architectures, Intel's had a weakness: the boot ROM, in this case. An early-stage vulnerability in ROM enables control over the reading of the Chipset Key and generation of all other encryption keys. One of these keys is for the Integrity Control Value Blob (ICVB). With this key, attackers can forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect. This is functionally equivalent to a breach of the private key for the Intel CSME firmware digital signature, but limited to a specific platform."

Microsoft today has released several microcode updates for Intel CPUs. The updates are meant to be applied in a case-by-case basis under their Windows 10 operating system, and these updates target several releases of that OS (ranging from version 1507 through version 1903/1909). These address several vulnerability exploits related to side-channel and speculative execution attacks on Intel CPUs.

The updates need to be installed specifically for the Windows OS version you're rocking, and on systems with CPUs affected by the vulnerabilities and covered by this microcode update release. These include Intel's Denverton (Atom C3000 series); Sandy Bridge, Sandy Bridge E and EP (2000 and 3000 series), Valleyview (Atom Z3000 series) and Whiskey Lake U CPUs (8000U series, 5000U series, and 4200U series). These updates must be installed manually by users.

Another day, another speculative execution vulnerability found inside Intel processors. This time we are getting a new vulnerability called "CacheOut", named after the exploitation's ability to leak data stored inside CPU's cache memory. Dubbed CVE-2020-0549: "L1D Eviction Sampling (L1Des) Leakage" in the CVE identifier system, it is rated with a CVSS score of 6.5. Despite Intel patching a lot of similar exploits present on their CPUs, the CacheOut attack still managed to happen.

The CacheOut steals the data from the CPU's L1 cache, and it is doing it selectively. Instead of waiting for the data to become available, the exploit can choose which data it wants to leak. The "benefit" of this exploit is that it can violate almost every hardware-based security domain meaning that the kernel, co-resident VMs, and SGX (Software Guard Extensions) enclaves are in trouble. To mitigate this issue, Intel provided a microcode update to address the shortcomings of the architecture and they recommended possible mitigations to all OS providers, so you will be protected once your OS maker releases a new update. For a full list of processors affected, you can see this list. Additionally, it is worth pointing out that AMD CPUs are not affected by this exploit.

If you haven't updated your AMD Radeon drivers in a while, here's one major reason to. The company secretly patched four major security vulnerabilities affecting Radeon GPUs, in its recent Adrenalin 20.1.1 drivers, with no mention of doing so in its changelog. Talos Intelligence reports four vulnerabilities, which are are chronicled under CVE-2019-5124, CVE-2019-5146, CVE-2019-5147 and CVE-2019-5183. This class of attacks exploits a vulnerability in the AMD Radeon driver file ATIDXX64.dll, which can lead to denial of service or even remote code execution. What makes things much more serious is that this attack vector can be used to exploit the host machine from a VM (tested with VMWare). It even seems possible to trigger the vulnerability from a web page, through WebGL (which allows running 3D applications on a remote website). The vulnerabilities were tested on Radeon RX 550 / 550 Series VMware Workstation 15 (15.5.0 build-14665864) with Windows 10 x64 as guest VM, but there is no reason to assume that the issue is limited to just RX 550 as the AMD shader compiler shares a common code basis for all recent DirectX 12 GPUs.

All vulnerabilities rely on a common attack vector: specially crafted shader code that exploits bugs in the shader compiler. Even though HLSL shader code looks similar to assembly, it actually is a relatively high-level language that gets optimized and compiled by the graphics driver. VMWare's graphics acceleration lets you run 3D graphics in virtual machines, by passing along rendering info to the host GPU and then funneling the output back into the VM. Since the shader code gets compiled using the graphics driver of the host OS, this creates interesting opportunities for attacks.

A group of cybersecurity researchers have discovered a new security vulnerability affecting Intel processors, which they've craftily named "Plundervolt," a portmanteau of the words "plunder" and "undervolt." Chronicled under CVE-2019-11157, it was first reported to Intel in June 2019 under its security bug-bounty programme, so it could secretly develop a mitigation. With the 6-month NDA lapsing, the researchers released their findings to the public. Plundervolt is described by researchers as a way to compromise SGX (software guard extensions) protected memory by undervolting the processor when executing protected computations, to a level where SGX memory-encryption no longer protects data. The researchers have also published proof-of-concept code.

Plundervolt is different from "Rowhammer," in that it flips bits inside the processor, before they're written to the memory, so SGX doesn't protect them. Rowhammer doesn't work with SGX-protected memory. Plundervolt requires root privileges as software that let you tweak vCore require ring-0 access. You don't need direct physical access to the target machine, as tweaking software can also be remotely run. Intel put out security advisory SA-00298 and is working with motherboard vendors and OEMs to release BIOS updates that pack a new microcode with a mitigation against this vulnerability. The research paper can be read here.

All Intel CPU microarchitectures since 2013 are vulnerable to a new class of "Zombieload," attacks, chronicled under "Zombieload v2" (CVE-2019-11135). This is the fifth kind of microarchitectural data sampling (MDS) vulnerability, besides the four already disclosed and patched against in Q2-2019. The vulnerability was kept secret by the people who discovered it, as Intel was yet to develop a mitigation against it. There is no silicon-level hardening against it, and Intel has released a firmware-level mitigation that will be distributed by motherboard manufacturers as BIOS updates, or perhaps even OS vendors. While Intel's latest enterprise and HEDT microarchitecture, "Cascade Lake" was thought to be immune to "Zombieload," it's being reported that "Zombieload v2" attacks can still compromise a "Cascade Lake" based server or HEDT that isn't patched.

"Zombieload v2" is an exploitation of the Asynchronous Abort operation of Transactional Synchronization Extensions (TSX), which occurs when malware creates read operation conflicts within the CPU. This reportedly leaks data about what else is being processed. "The main advantage of this approach is that it also works on machines with hardware fixes for Meltdown, which we verified on an i9-9900K and Xeon Gold 5218," reads the latest version of the Zombieload whitepaper that's been updated with "Zombieload v2" information. TSX is a requisite for "Zombieload v2," and all Intel microarchitectures since "Haswell" feature it. AMD processors are inherently immune to "Zombieload v2" as they lack TSX. Intel downplayed the severity or prevalence of "Zombieload v2," but dispatched microcode updates flagged "critical" nevertheless.

NVIDIA today released GeForce Software version 441.12 WHQL. These drivers come game-ready for "Red Dead Redemption 2," which is going live tomorrow (November 5th). The drivers add or improve optimization for "Need for Speed Heat" and "Borderlands 3." The drivers fix a white-screen game crash associated with "Super Robot Wars V." With these drivers, NVIDIA is also addressing a security vulnerability, which isn't documented publicly yet, but will be released on Nov 6th, as "Security Bulletin 4907". Right now it is only briefly described as "Added security updates for driver components". Grab the drivers from the link below.

DOWNLOAD: NVIDIA GeForce Software 441.12 WHQLThe change-log follows.

DDIO, or Direct Data I/O, is an Intel-exclusive performance enhancement that allows NICs to directly access a processor's L3 cache, completely bypassing the a server's RAM, to increase NIC performance and lower latencies. Cybersecurity researchers from the Vrije Universiteit Amsterdam and ETH Zurich, in a research paper published on Tuesday, have discovered a critical vulnerability with DDIO that allows compromised servers in a network to steal data from every other machine on its local network. This include the ability to obtain keystrokes and other sensitive data flowing through the memory of vulnerable servers. This effect is compounded in data centers that have not just DDIO, but also RDMA (remote direct memory access) enabled, in which a single server can compromise an entire network. RDMA is a key ingredient in shoring up performance in HPCs and supercomputing environments. Intel in its initial response asked customers to disable DDIO and RDMA on machines with access to untrusted networks, while it works on patches.

The NetCAT vulnerability spells big trouble for web hosting providers. If a hacker leases a server in a data-center with RDMA and DDIO enabled, they can compromise other customers' servers and steal their data. "While NetCAT is powerful even with only minimal assumptions, we believe that we have merely scratched the surface of possibilities for network-based cache attacks, and we expect similar attacks based on NetCAT in the future," the paper reads. We hope that our efforts caution processor vendors against exposing microarchitectural elements to peripherals without a thorough security design to prevent abuse." The team also published a video briefing the nature of NetCAT. AMD EPYC processors don't support DDIO.The video detailing NetCAT follows.

Yet another CPU vulnerability was discovered today, called SWAPGS, revealed under the code CVE-2019-1125, as it is referred to in the industry. The vulnerability was discovered twelve months ago and got privately reported to Intel by a security researcher. It's supposedly present on both AMD and Intel CPUs, but was only proven to work on Intel platforms by Bitdefender security researchers. Red Hat issued a statement which states that both platforms are affected and that users should upgrade their systems as soon as possible. Microsoft already implemented a fix with its "Patch Tuesday" update for last month, so if you updated your OS recently, you are already protected against SWAPGS.

AMD issued as statement as well, in which it says: "AMD is aware of new research claiming new speculative execution attacks that may allow access to privileged kernel data. Based on external and internal analysis, AMD believes it is not vulnerable to the SWAPGS variant attacks because AMD products are designed not to speculate on the new GS value following a speculative SWAPGS. For the attack that is not a SWAPGS variant, the mitigation is to implement our existing recommendations for Spectre variant 1."

AMD in its technical brief revealed that its Zen 2 microarchitecture has hardware mitigation against the Spectre V4 speculative store bypass vulnerability. The current generation "Zen" and "Zen+" microarchitectures have OS-level mitigation. A hardware mitigation typically has less of a performance overhead than a software mitigation deployed at the OS or firmware level. In addition, just like older generations of "Zen," the new "Zen 2" microarchitecture is inherently immune to Meltdown, Foreshadow, Spectre V3a, Lazy FPU, Spoiler, and the recently discovered MDS vulnerability. In comparison, the 9th generation Core "Coffee Lake Refresh" processors still rely on software or microcode-level mitigation for Spectre V4, Spectre V3a, MDS, and RIDL.

Cybersecurity researchers at the Vrije Universiteit Amsterdam, also known as VU Amsterdam, allege that Intel tried to bribe them to suppress knowledge of the latest processor security vulnerability RIDL (rogue in-flight data load), which the company made public on May 14. Dutch publication Nieuwe Rotterdamsche Courant reports that Intel offered to pay the researchers a USD $40,000 "reward" to allegedly get them to downplay the severity of the vulnerability, and backed their offer with an additional $80,000. The team politely refused both offers.

Intel's security vulnerability bounty program is shrouded in CYA agreements designed to minimize Intel's losses from the discovery of a new vulnerability. Under its terms, once a discoverer accepts the bounty reward, they enter into a NDA (non-disclosure agreement) with Intel, to not disclose their findings or communicate in the regard with any other person or entity than with certain authorized people at Intel. With public knowledge withheld, Intel can work on mitigation and patches against the vulnerability. Intel argues that information of vulnerabilities becoming public before it's had a chance to address them would give the bad guys time to design and spread malware that exploits the vulnerability. This is an argument the people at VU weren't willing to buy, and thus Intel is forced to disclose RIDL even as microcode updates, software updates, and patched hardware are only beginning to come out.Update: (17/05): An Intel spokesperson commented on this story.

AMD in a statement confirmed that its processors are unaffected by the RIDL (Rogue In-Flight Data Load) and Fallout vulnerabilities. The company however worded its statement in CYA language, just to be safe. "...we believe our products are not susceptible to 'Fallout' or 'RIDL' because of the hardware protection checks in our architecture. We have not been able to demonstrate these exploits on AMD products and are unaware of others having done so," reads the AMD statement put out late Tuesday (14th May).

AMD came to these conclusions on the basis of its own testing and discussions with the researchers who discovered RIDL. It's important to note here, that the "Fallout" vulnerability AMD is referring to in this statement is the one which is part of four MDS vulnerabilities Intel disclosed yesterday, and not the identically named "Fallout" vulnerability discovered by CTS Labs in 2018, allegedly affecting secure memory management of AMD "Zen" processors.

Ouch doesn't even begin to describe how much that headline hurt. As far as speculative execution goes, it's been well covered by now, but here's a refresher. Speculative execution essentially means that your CPU tries to think ahead of time on what data may or may not be needed, and processes it before it knows it's needed. The objective is to take advantage of concurrency in the CPU design, keeping processing units that would otherwise be left idle to process and deliver results on the off-chance that they are indeed required by the system: and when they are called for, the CPU saves time by not having to process them on the fly and already having them available.

The flaws have been announced by Intel in coordination with Austrian university TU Graz, Vrije Universiteit Amsterdam, the University of Michigan, the University of Adelaide, KU Leuven in Belgium, Worcester Polytechnic Institute, Saarland University in Germany and security firms Cyberus, BitDefender, Qihoo360 and Oracle. While some of the parties involved have named the four identified flaws with names such as "ZombieLoad", "Fallout", and RIDL, or "Rogue In-Flight Data Load", Intel is using the PEGI-13 "Microarchitectural Data Sampling (MDS)" name.