„a hardened kernel is no longer optional“. After ME, another Intel security madmess. Intel is contributing to the kernel and just as Google selling Chromebooks probably wants to see this fixed – so it would be great for them to really dedicate resources to this mess and not rely on the open source community to fix their problems. (also see: „Replace Your Exploit-Ridden Firmware (BIOS, UEFI, Intel ME) with Linux – Ronald Minnich, Google„)
„THIS IS NOT A TEST-DRILL, IT IS AN EMERGENCY SITUATION for the Open Source community and hardware vendors to react on shit that happens – because nobody is perfect“
Can be patched/updated/fixed by as completely as possible separating kernel-RAM and userspace-RAM. (Linux unter Kernel Page-table Isolation (KPTI)))
“Whereas Meltdown is an urgent crisis, Spectre affects virtually all fast microprocessors. We’ve really screwed up,” Kocher (TEDx) told the New York Times. “There’s been this desire from the industry to be as fast as possible and secure at the same time. Spectre shows that you cannot have both.” (src)
„The Value of the System is the value of the features minus the risks that it creates. If we can’t cope with those computer security problems – the net value of the systems that we produce is going to be falling – and the more complicated systems will be less valuable than the one’s that we already have.“ (Paul Kocher)
Means: An old Nokia phone is more valuable than an IPhone 10 if it can’t be hacked for the simple reason of having a smaller attack surface (less software running, less complex chips in use) – if twitter isn’t working might not be as important to you as being unable to call someone.
- Code utilizing this exploit works on Windows, Linux, etc., as this is not a software- but a hardware issue.
- It is possible to dump arbitrary kernel memory with unprivileged user space applications.
- Reading kernel memory implies reading the memory of the whole system on most 64 bit operating systems, i.e. also memory from address spaces of other processes.
- Fully virtualized machines are not affected (guest user space can still read from guest kernel space, but not from host kernel space).
- Paravirtualized machines are affected (e.g. Xen PV).
- Container solutions like Docker, LXC, OpenVZ are all equally affected.
- The Linux KPTI / KAISER patches mitigate Meltdown effects on Linux.
- Most modern processors, in particular with Intel microarchitecture since 2010, are affected.
- We have no evidence that this attack is successfully deployable on ARM or AMD, although the underlying principle applies to all contemporary superscalar CPUs.
- Meltdown is distinct from the Spectre attacks, which became public at the same time.
Instead of pointing fingers – it would be great for hardware vendors such as ARM, Intel, AMD, Apple, Samsung, Huawai, HTC and so on:
- Albert Einstein: Energy = Matter = Energy. Software = Hardware = Software.
- simplicity is key – if you can simplify hard and software – you should. If you can achieve the same goal with less complexity (less soft and hardware) – you really should. It will be faster and more secure.
- one way to simplify: stop running hidden closed source on hidden closed source chips on our mobile, laptop and desktop workstations
- do high quality software-hardware specifications and constantly work to improve them: constantly improve on your self-testing inhouse-error-correction before selling flawed stuff to the world (quality and security testing assurance) the world should and might sue you for this to avoid that something like this happens ever again.
- Don’t expect it to be a „one time only“ thing – humans make mistakes in soft and hardware. Will Intel and ARM recall all the CPUs it has build in the last 10 years and replace them? How seriously economically damaging this could become for intel can be seen by CEO Brian Krzanich has sold all his Intel stocks he was allowed to sell.
„You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of “zero-day” vulnerabilities to target, for example, human rights activists or to conduct industrial espionage. This needs to stop. We think more can be done to tackle this problem.“
You can fix this problem with OS security updates – when they get available.
it is a hardware bug thus affects all sorts of OS, Linux, OSX, Win
Always remember that exploits are often used in combination.
test programs for linux
„The key idea of DrK is to exploit an unusual behavior of TSX in handling erroneous situations inside a transaction“
mirror: Breaking Kernel Address Space Layout Randomization with Intel TSX Yeongjin Jang, Sangho Lee, and Taesoo Kim Georgia Institute of Technology drk-bh.pdf (src)
./timing/info.py Get processor info from /proc/cpuinfo model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz Error, your processor does not support Intel TSX; # thanks god :-D Error: cannot open /proc/cpuinfo
The DrK (De-randomizing Kernel ASLR) attack
DrK is an attack that breaks kernel address space layout randomization (KASLR) by exploiting TLB and decoded i-cache side channel. To reliably exploit the side channels, the DrK attack took advantage of Intel TSX (Transactional Synchronization eXtension). One surprising behavior of TSX, which is essentially the root cause of this security loophole, is that it aborts a transaction without notifying the underlying kernel even when the transaction fails due to a critical error, such as a page fault or an access violation, which traditionally requires kernel intervention. DrK turns this property into a precise timing channel that can determine the mapping status (i.e., mapped versus unmapped) and execution status (i.e., executable versus non-executable) of the privileged kernel address space. Since such behavior is on the hardware level, DrK is universally applicable to all OSes, even in virtualized environments, and generates no visible footprint, making it difficult to detect in practice. Therefore, DrK can break the KASLR of all major OSes (i.e., Windows, Linux, and OS X) with near-perfect accuracy in under a second.
- DrK paper (ACM CCS’16): http://www.cc.gatech.edu/~yjang37/assets/papers/2016/jang:drk-ccs.pdf
- Talk at Black Hat USA: https://www.youtube.com/watch?v=923QRTsUf3E
what you can do
There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre ( LLVM patch).
If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already. And then keep updating them over the next few weeks, we are still working out lots of corner case bugs given that the testing involved here is complex given the huge variety of systems and workloads this affects. If your distro does not have kernel updates, then I strongly suggest changing distros right now.
However there are lots of systems out there that are not running “normal” Linux distributions for various reasons (rumor has it that it is way more than the “traditional” corporate distros). They rely on the LTS kernel updates, or the normal stable kernel updates, or they are in-house franken-kernels. For those people here’s the status of what is going on regarding all of this mess in the upstream kernels you can use.
Meltdown – x86
Right now, Linus’s kernel tree contains all of the fixes we currently know about to handle the Meltdown vulnerability for the x86 architecture.
ENABLE the CONFIG_PAGE_TABLE_ISOLATION kernel build option, and rebuild and reboot and all should be fine.
However, Linus’s tree is currently at 4.15-rc6 + some outstanding patches. 4.15-rc7 should be out tomorrow, with those outstanding patches to resolve some issues, but most people do not run a -rc kernel in a “normal” environment.
Because of this, the x86 kernel developers have done a wonderful job in their development of the page table isolation code, so much so that the backport to the latest stable kernel, 4.14, has been almost trivial for me to do. This means that the latest 4.14 release (4.14.12 at this moment in time), is what you should be running. 4.14.13 will be out in a few more days, with some additional fixes in it that are needed for some systems that have boot-time problems with 4.14.12 (it’s an obvious problem, if it does not boot, just add the patches now queued up.)
There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows 10, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre ( LLVM patch).
BEFORE UPDATING: BACKUP YOUR SYSTEM
especially debian dist-upgrade can RUIN YOUR DAY!
In CentOS you should upgrade your system to kernel x86_64 3.10.0-693.11.6.el7
x86_64: 320ab3bd00bd1f051c69f65f2d4cd6ab64585f977d9cd7a52e64e8f8147894fc kernel-3.10.0-693.11.6.el7.x86_64.rpm # which can be done with a simple (backup/snapshot first!) yum update && yum upgrade rpm -q --changelog kernel | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'; # verify spectre fix
my guide to (hopefully) get the latest stable kernel 🙂
i WILL NOT RECOMMEND apt dist-upgrade!
IT CAN RUIN YOUR DAY!
Unfortunately it is considered „normal“ to go from Debian8 to Debian9 by REINSTALL not UPGRADE. (really it is like this, you can try but without backup is insane and it comes without warranty!)
YOU HAVE BEEN WARNED 🙂
In Debian Stretch the problem is fixed with kernel version x > 4.9.65-3+deb9u2
In Debian Sid the problem is fixed with kernel version x > 4.14.12-2
Package : linux CVE ID : CVE-2017-5754 Multiple researchers have discovered a vulnerability in Intel processors, enabling an attacker controlling an unprivileged process to read memory from arbitrary addresses, including from the kernel and all other processes running on the system. This specific attack has been named Meltdown and is addressed in the Linux kernel for the Intel x86-64 architecture by a patch set named Kernel Page Table Isolation, enforcing a near complete separation of the kernel and userspace address maps and preventing the attack. This solution might have a performance impact, and can be disabled at boot time by passing `pti=off' to the kernel command line. We also identified a regression for ancient userspaces using the vsyscall interface, for example chroot and containers using (e)glibc 2.13 and older, including those based on Debian 7 or RHEL/CentOS 6. This regression will be fixed in a later update. The other vulnerabilities (named Spectre) published at the same time are not addressed in this update and will be fixed in a later update. For the oldstable distribution (jessie), this problem will be fixed in a separate update. For the stable distribution (stretch), this problem has been fixed in version 4.9.65-3+deb9u2. We recommend that you upgrade your linux packages. https://lists.debian.org/debian-security-announce/2018/msg00000.html src: https://security-tracker.debian.org/tracker/CVE-2017-5754
Multiple researchers have discovered a vulnerability in Intel processors, enabling an attacker controlling an unprivileged process to read memory from arbitrary addresses, including from the kernel and all other processes running on the system.
This specific attack has been named Meltdown and is addressed in the Linux kernel for the Intel x86-64 architecture by a patch set named Kernel Page Table Isolation, enforcing a near complete separation of the kernel and userspace address maps and preventing the attack. This solution might have a performance impact, and can be disabled at boot time by passing
to the kernel command line.
We also identified a regression for ancient userspaces using the vsyscall interface, for example chroot and containers using (e)glibc 2.13 and older, including those based on Debian 7 or RHEL/CentOS 6. This regression will be fixed in a later update.
The other vulnerabilities (named Spectre) published at the same time are not addressed in this update and will be fixed in a later update.
For the oldstable distribution (jessie), this problem will be fixed in a separate update.
For the stable distribution (stretch), this problem has been fixed in version 4.9.65-3+deb9u2.
We recommend that you upgrade your linux packages.
For the detailed security status of linux please refer to its security tracker page at: https://security-tracker.debian.org/tracker/linux
test programs for windows
did not really work for me and windows 7 ultimate win 32 bit, this is as far as i got:
- copy all the files from C:\Users\USERNAME\AppData\Local\Programs\Python\Python36-32 to where you unpacked In-Spectre-Meltdown
- run the C:\Spectre-Meltdown>In-Spectre_meltdown.py
This tool allows to check speculative execution side-channel attacks that affect many modern processors and operating systems designs. CVE-2017-5754 (Meltdown) and CVE-2017-5715 (Spectre) allows unprivileged processes to steal secrets from privileged processes. These attacks present 3 different ways of attacking data protection measures on CPUs enabling attackers to read data they shouldn’t be able to.
This tool is originally based on Microsoft: https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in
Customers using Surface products need to apply both firmware and software updates. See Microsoft Knowledge Base Article 4073065 article for more information.
6. Why aren’t Windows Server 2008 and Windows Server 2012 platforms getting an update? When can customers expect the fix?
Addressing a hardware vulnerability with a software update presents significant challenges with some operating systems requiring extensive architectural changes. Microsoft continues to work with affected chip manufacturers and investigate the best way to provide mitigations
Customers using Windows server operating systems including Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2, and Windows Server 2016 need to apply firmware and software updates as well as configure protections. See Microsoft Knowledge Base Article 4072698 for additional information, including workarounds.
back to article:
I would personally like to thank Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, Peter Zijlstra, Josh Poimboeuf, Juergen Gross, and Linus Torvalds for all of the work they have done in getting these fixes developed and merged upstream in a form that was so easy for me to consume to allow the stable releases to work properly. Without that effort, I don’t even want to think about what would have happened.
For the older long term stable (LTS) kernels, I have leaned heavily on the wonderful work of Huge Dickens, Dave Hansen, Jiri Kosina and Borislav Petkov to bring the same functionality to the 4.4 and 4.9 stable kernel trees. I had also had immense help from Guenter Roeck, Kees Cook, Jamie Iles, and many others in tracking down nasty bugs and missing patches. I want to also call out David Woodhouse, Eduardo Valentin, Laura Abbott, and Rik van Riel for their help with the backporting and integration as well, their help was essential in numerous tricky places.
These LTS kernels also have the CONFIG_PAGE_TABLE_ISOLATION build option that should be enabled to get complete protection.
As this backport is very different from the mainline version that is in 4.14 and 4.15, there are different bugs happening, right now we know of some VDSO issues that are getting worked on, and some odd virtual machine setups are reporting strange errors, but those are the minority at the moment, and should not stop you from upgrading at all right now. If you do run into problems with these releases, please let us know on the stable kernel mailing list.
If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. The lack of patches to resolve the Meltdown problem is so minor compared to the hundreds of other known exploits and bugs that your kernel version currently contains. You need to worry about that more than anything else at this moment, and get your systems up to date first.
Also, go yell at the people who forced you to run an obsoleted and insecure kernel version, they are the ones that need to learn that doing so is a totally reckless act.
Meltdown – ARM64
Right now the ARM64 set of patches for the Meltdown issue are not merged into Linus’s tree. They are staged and ready to be merged into 4.16-rc1 once 4.15 is released in a few weeks. Because these patches are not in a released kernel from Linus yet, I can not backport them into the stable kernel releases (hey, we have rules for a reason…)
Due to them not being in a released kernel, if you rely on ARM64 for your systems (i.e. Android), I point you at the Android Common Kernel tree All of the ARM64 fixes have been merged into the 3.18, 4.4, and 4.9 branches as of this point in time.
I would strongly recommend just tracking those branches as more fixes get added over time due to testing and things catch up with what gets merged into the upstream kernel releases over time, especially as I do not know when these patches will land in the stable and LTS kernel releases at this point in time.
For the 4.4 and 4.9 LTS kernels, odds are these patches will never get merged into them, due to the large number of prerequisite patches required. All of those prerequisite patches have been long merged and tested in the android-common kernels, so I think it is a better idea to just rely on those kernel branches instead of the LTS release for ARM systems at this point in time.
Also note, I merge all of the LTS kernel updates into those branches usually within a day or so of being released, so you should be following those branches no matter what, to ensure your ARM systems are up to date and secure.
Now things get “interesting”…
Again, if you are running a distro kernel, you might be covered as some of the distros have merged various patches into them that they claim mitigate most of the problems here. I suggest updating and testing for yourself to see if you are worried about this attack vector
For upstream, well, the status is there is no fixes merged into any upstream tree for these types of issues yet. There are numerous patches floating around on the different mailing lists that are proposing solutions for how to resolve them, but they are under heavy development, some of the patch series do not even build or apply to any known trees, the series conflict with each other, and it’s a general mess.
This is due to the fact that the Spectre issues were the last to be addressed by the kernel developers. All of us were working on the Meltdown issue, and we had no real information on exactly what the Spectre problem was at all, and what patches were floating around were in even worse shape than what have been publicly posted.
Because of all of this, it is going to take us in the kernel community a few weeks to resolve these issues and get them merged upstream. The fixes are coming in to various subsystems all over the kernel, and will be collected and released in the stable kernel updates as they are merged, so again, you are best off just staying up to date with either your distribution’s kernel releases, or the LTS and stable kernel releases.
It’s not the best news, I know, but it’s reality. If it’s any consolation, it does not seem that any other operating system has full solutions for these issues either, the whole industry is in the same boat right now, and we just need to wait and let the developers solve the problem as quickly as they can.
The proposed solutions are not trivial, but some of them are amazingly good. The Retpoline post from Paul Turner is an example of some of the new concepts being created to help resolve these issues. This is going to be an area of lots of research over the next years to come up with ways to mitigate the potential problems involved in hardware that wants to try to predict the future before it happens.
Right now, I have not seen patches for any other architectures than x86 and arm64. There are rumors of patches floating around in some of the enterprise distributions for some of the other processor types, and hopefully they will surface in the weeks to come to get merged properly upstream. I have no idea when that will happen, if you are dependant on a specific architecture, I suggest asking on the arch-specific mailing list about this to get a straight answer.
Again, update your kernels, don’t delay, and don’t stop. The updates to resolve these problems will be continuing to come for a long period of time. Also, there are still lots of other bugs and security issues being resolved in the stable and LTS kernel releases that are totally independent of these types of issues, so keeping up to date is always a good idea.
Right now, there are a lot of very overworked, grumpy, sleepless, and just generally pissed off kernel developers working as hard as they can to resolve these issues that they themselves did not cause at all. Please be considerate of their situation right now. They need all the love and support and free supply of their favorite beverage that we can provide them to ensure that we all end up with fixed systems as soon as possible.
what you could also do
useless for ARM because it does not have a good source of entropy?
to harden the kernel further enable KASLR (Kernel Address Space Layout Randomization) feature, the kernel needs to be built with CONFIG_RANDOMIZE_BASE=y
„Randomization requires a good source of entropy, and arm64 does not have an architected means of obtaining entropy (e.g., via an instruction), nor does its early execution environment have access to platform specific peripherals that can supply such entropy. This means it is left to the bootloader to generate a KASLR seed, and pass it to the core kernel via the /chosen/kaslr-seed DT property.
For platforms that boot via UEFI, the UEFI stub in the arm64 kernel will attempt to locate the EFI_RNG_PROTOCOL, and invoke it to supply a kaslr-seed. On top of that, it will use this protocol to randomize the physical load address of the kernel Image.
QEMU in UEFI mode supports this protocol if the virtio-rng-pci device is made available. Bare metal platforms like the Celloboard or QDF2432 implement this protocol natively as well.“
Before updating system…
First, always keep backups. Second, note down the Linux kernel version running the following command:
Please note that fix currently available for the following distros for sure:
- RHEL 7.x
- CentOS 7.x
- Fedora 26/27
- Debian stretch
- Arch Linux
- Gentoo Linux
Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux
Type the following yum command:
$ sudo yum update
$ uname -r
Run the following dnf command if you are using a Fedora Linux:
Fix the Meltdown on a Debian/Ubuntu Linux
$ sudo apt-get update
## better run the following instead of 'sudo apt-get upgrade'
$ sudo apt-get dist-upgrade
„it affects potentially all out-of-order execution Intel processors since 1995, except Itanium and pre-2013 Atoms. It definitely affects out-of-order x86-64 Intel CPUs since 2011.“ (src)
list of arm cpus: https://developer.arm.com/support/security-update
The Meltdown vulnerability primarily affects Intel microprocessors. It is thought not to affect AMD microprocessors. Intel has countered that the flaws affect all processors, but AMD has denied this, claiming that there is zero chance for their processors to be affected by Meltdown due to architectural differences of their processors. Researchers have indicated that the Meltdown vulnerability is exclusive to Intel processors, while the Spectre vulnerability can possibly affect some Intel, AMD, and ARM processors. Specifically, processors with speculative execution are affected with these vulnerabilities. Intel and ARM processors are affected the most, while AMD processors are minimally affected. Google has reported that every Intel processor since 1995 with out-of-order execution is potentially vulnerable to the Meltdown vulnerability. (This excludes Itanium and pre-2013 Intel Atom CPUs) Intel introduced speculative execution to their processors with Intel’s P6 family microarchitecture with the Pentium Pro IA-32 microprocessor in 1995.
ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected. However, the ARM Cortex-A75 core is affected directly by the Meltdown vulnerability, and cores Cortex-A15, Cortex-A57, and Cortex-A72 are affected by variations of the Meltdown vulnerability. This contradicts some early statements made about the Meltdown vulnerability as being Intel only.
A large portion of the current mid-range Android handsets use the Cortex-A53 or Cortex-A55 in an octa-core arrangement and are not affected by either the Meltdown or Spectre vulnerability as they don’t do out-of-order execution. This includes devices with the Qualcomm Snapdragon 630, Snapdragon 626, Snapdragon 625, and all Snapdragon 4xx processors based on A53 or A55 cores. Also, all Raspberry Pi computers are not vulnerable to either Meltdown or Spectre.
„Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents. Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. Depending on the cloud provider’s infrastructure, it might be possible to steal data from other customers.“
All 3 vendors effected: ARM, Intel, AMD. Intel is more affected on hardware-level and ARM and AMD more on the software-level.
„It is basically a backdoor“ „run malicious software“ „ransomware“
This affects EVERYBODY.
Bugs in modern computers leak passwords and sensitive data – e.g. from your BROWSER!
Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents.
Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. Depending on the cloud provider’s infrastructure, it might be possible to steal data from other customers.
Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.
If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.
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
Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
Who reported Meltdown?
Meltdown was independently discovered and reported by three teams:
- Jann Horn (Google Project Zero),
- Werner Haas, Thomas Prescher (Cyberus Technology),
- Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology)
Who reported Spectre?
Spectre was independently discovered and reported by two people:
- Jann Horn (Google Project Zero) and
- Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61)
Most certainly, yes.
Probably not. The exploitation does not leave any traces in traditional log files.
While possible in theory, this is unlikely in practice. Unlike usual malware, Meltdown and Spectre are hard to distinguish from regular benign applications. However, your antivirus may detect malware which uses the attacks by comparing binaries after they become known.
If your system is affected, our proof-of-concept exploit can read the memory content of your computer. This may include passwords and sensitive data stored on the system.
We don’t know.
Naming of the FIX:
Several people including Linus requested to change the KAISER name.
We came up with a list of technically correct acronyms:
User Address Space Separation, prefix uass_
Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_
but we are politically correct people so we settled for
Kernel Page Table Isolation, prefix kpti_
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.
Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location. For a more technical discussion we refer to the papers ( Meltdown and Spectre)
The bug basically melts security boundaries which are normally enforced by the hardware.
The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.
CVE-2017-5753 and CVE-2017-5715 are the official references to Spectre. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.
CVE-2017-5754 is the official reference to Meltdown. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.
|Logo||Logo with text||Code illustration|
|Meltdown||PNG / SVG||PNG / SVG||PNG / SVG|
|Spectre||PNG / SVG||PNG / SVG||PNG / SVG|
|Intel||Security Advisory / Newsroom|
|Microsoft||Security Guidance / Information regarding anti-virus software / Azure Blog|
|Project Zero Blog / Need to know|
|Red Hat||Vulnerability Response|
|LLVM||Spectre (Variant #2) Patch|
|MITRE||CVE-2017-5715 / CVE-2017-5753 / CVE-2017-5754|
We would like to thank Intel for awarding us with a bug bounty for the responsible disclosure process, and their professional handling of this issue through communicating a clear timeline and connecting all involved researchers. Furthermore, we would also thank ARM for their fast response upon disclosing the issue.
This work was supported in part by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 681402).
This work was supported in part by NSF awards #1514261 and #1652259, financial assistance award 70NANB15H328 from the U.S. Department of Commerce, National Institute of Standards and Technology, the 2017-2018 Rothschild Postdoctoral Fellowship, and the Defense Advanced Research Project Agency (DARPA) under Contract #FA8650-16-C-7622.