163

It's not even remotely true. Although you can use a Meltdown or Spectre attack to inspect the internals of a program in the way a debugger can, a proper debugger is much faster, easier, and more reliable.


119

This answer is an attempt at addressing simply the main concerns. The details here might not be exemplary accurate, or complete. I'll try to link to more detailed explanations when possible. What is speculative execution and what does it do? Speculative execution is a feature of modern processors that comes as an optimisation. To allow for the parallel ...


85

The patch against Meltdown is kernel only. Docker containers run within the kernel of the host system. This means the resistance against Meltdown depends on the host kernel only. In other words: you don't need patches against Meltdown in the docker image and you cannot patch against Meltdown in the docker image.


85

the only point of easy penetration to a system seems to be via javascript running in a web browser. How about Flash? Java? Silverlight? VBA in an office document? Any applications that load web-pages inside of themselves? The thing is, once a box has rogue code running, it's already compromised. With code running under your user account a lot can be ...


78

A normal debugger uses documented API/syscall/instruction to look at state of a process it is permitted to access. Just being a debugger alone cannot bypass OS memory protection, otherwise anyone who knows how to download stuff can gain admin access on any system. Meltdown and spectre attacks use (previously) undocumented and unintended side-effects of ...


45

First of all you would not normally expect kernel memory to be mapped in a GPU. Even if you did modern GPU's generally don't have much in the way of support for sharing memory between processes. There have certainly been research papers on speculative execution inside of a GPU - Speculative Execution on GPU: An Exploratory Study; Liu, Eisenbeis, Gaudiot - ...


35

Basically, if you run code from untrusted sources on a machine that has data you don't want that code to have access to, you need to patch. Desktop computers should be patched because they've got an unfortunate habit of encountering untrusted code; shared-hosting servers, particularly virtual private server hosts, must be patched, because Meltdown lets one ...


33

The processors that were already announced and are about to be launched in the near future will still be vulnerable to both Spectre v2 and Meltdown if patches and/or firmware is not applied correctly. Spectre v1 was not entirely fixed with the latest patches. Most recent products have patches available, although not always functioning very well. You can ...


31

In my world, applying patches is a given. We're going to do it and it takes an exception to NOT apply a patch. Right now, those are exploits we know about for Spectre and Meltdown. However, what's to guarantee that there won't be more? Further, many exploits out there (such as Wannacry/Petya) involve systems that aren't patched for this known issue. I'd ...


24

The references you mention don't conflict with each other. The first one claims for Meltdown that "Fully virtualized machines are not affected". The second one claims that the product is "vulnerable to Bounds Check Bypass and Branch Target Injection issues". These issues are not the Meltdown but the Spectre vulnerability. Or to summarize: CVE-2017-5753 - ...


22

I heard from a guy that's involved in low-level (assembler, C for drivers and OSes) programming, that meltdown and spectre weren't actually vulnerabilities discovered only so recently, but they were openly known as debug tools They may've gotten their wires crossed with another major vulnerability that was apparently recommended as a debugging tool about 1....


18

A GPU (Graphical Processing Unit) is not vulnerable to spectre/meltdown attacks. This is due to various reasons: A GPU is a completely differently designed processor. It does not run privileged code (e.g. kernel code). It does not run the OS. It is optimized for Vector calculations. Its micro code is build completely differently. It (most often) does not ...


17

Linux kernel logs the KPTI status on boot so, running the following command would print the status on patched kernels. If it prints nothing then, KPTI is disabled. dmesg -wH | grep 'Kernel/User page tables isolation' Linux Kernel 4.15rc6 has enabled KPTI(Kernel page-table isolation) and it has been back ported to Linux Kernel 4.14.11, 4.9.74, 4.4.109, 3....


17

Nvidia has released updates today dealing with the issues. So I would assume there are risks since they have created updates. http://us.download.nvidia.com/Windows/390.65/390.65-win10-win8-win7-desktop-release-notes.pdf Table 2.1 Security Updates for NVIDIA Software Vulnerabilities CVE ID NVIDIA Issue Number Description CVE-2017-5753 1975134 Computer ...


16

My understanding, first off, is that the OS / hypervisor patch only mitigates Meltdown, not Spectre. Second, you patch the hypervisor to prevent a VM from reading memory belonging to the kernel of the hypervisor. You patch the guest OS to prevent a process from reading memory belonging to the kernel of the guest OS. My understanding is that they are ...


13

No, interpreted or JIT'd code is also vulnerable According to multiple sources, the attack can be exploited via JavaScript in browsers. An excerpt from the Windows Blogs on Microsoft: Today, Google Project Zero published details of a class of vulnerabilities which can be exploited by speculative execution side-channel attacks. These techniques can be ...


13

The performance impact will vary greatly depending on what the program does. After the Meltdown patch (KPTI) whenever there is a context switch from user-space to kernel-space there is a significant overhead because of the frequent flushing of the kernel page tables. So this means that a program that relies on frequent context switching (like a database ...


12

The state of the art was non-existent. At the time of the Pentium Pro, the World Wide Web was four years old. Widespread use of shared hosting was about ten years in the future; if you suggested that people would want to run untrusted code provided by random third parties, they'd look at you like you'd grown a second head. Memory protection was about ...


11

My understanding of the issue is that it is a local information leak, where local means that the information are leaked "only" to processes on the same physical hardware and not (directly) to remote systems. And, it is an attack which was shown to be actually usable in practice to extract sensitive information, even it is currently not trivially to exploit. ...


11

*Update: This article seems to cover everything. The attack papers share many of the same authors and use similar but previously unknown attack vectors. Both exploits resulted from the same (or at least inter-related) bodies of research. Both were initially reported on the same date (2017-02-01) - CVE-2017-5754, CVE-2017-5753, CVE-2017-5715 So assuming ...


11

The Wray paper is about categorisation of covert channels, and from a rapid reading, it does reference an attack on a cache by two processes explicitly loading memory locations, but to be used as a timing mechanism. The Sibert paper, in the section 3.10 merely identifies the covert channel, not the actual Meltdown flaw. In conclusion, although it can ...


10

Things that do indicate the state of KPTI: In standard kernels, the strings Kernel/User page tables isolation: enabled or Kernel/User page tables isolation: force enabled on command line in the dmesg output means that the kernel is performing kernel page table isolation. The latter message additionally means that the kernel thinks page-table isolation is ...


10

In order to understand the threat from Meltdown, you need to understand how memory is organized in modern computers. The naive view of memory is that each memory address corresponds to a specific set of cells in RAM. This is called "physical addressing", and until about the early 1990s, was the most common way of handling memory in a computer. Under ...


9

Spectre. Intel SGX enclaves are indeed vulnerable to the Spectre attack as recently shown by researchers [1]. Their sample code manages to read a secret from protected SGX memory. Update Mar 7th, 2018. Meanhwile, another paper on the matter was published: SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution [2]. [1] https://github.com/lsds/...


9

They are both about equally terrible and still highly vulnerable to Spectre. Unfortunately, you would have to have access to confidential design documents in order to even begin answering this question. From (quasi-privileged) anecdotal evidence, AMD used to be really bad with setting lock bits (MMIO/MSR defaults, if I recall correctly), whereas Intel puts ...


8

On a supported kernel: dmesg | grep 'Kernel/User page tables isolation' will result in either enabled or disabled. If there is no result, then the kernel does not have support for KPTI.


8

I think you might be confusing the terms exploit and vulnerability. A vulnerability is a "hole" in the security, caused by a bug or poor implementation. They are detected by security researchers (white hat hackers), crackers (black hat hackers) or people in between (grey hat hackers). Those people are trying to break into the systems to either provide ...


8

Yes, because it can be used for privilege escalation. Usually, if an attack compromises a host, they only have user privileges. Using this vulnerability, they can escalate privileges by leaking credentials. Privilege escalation is important to attackers for carrying out many attacks, such as arp spoofing, SMB/LDAP relaying, token hijacking, credential ...


8

Install the patches unless you have a very strong reason not to. The approach you describe can basically be summed up as this: I know about exploit X. I could patch my OS to resolve exploit X, or I could carefully revisit every operation I do on my computer (including automated update tasks done for me). If none of those tasks provide a risk, then I do ...


7

Spectre works by causing the CPU to speculatively execute code selected by the attacker in the context of the target process. It does this by getting the branch predictor to guess incorrectly about which way an upcoming branch instruction will go, then looking for side effects of the code whose execution was discarded. Any CPU that performs speculative ...


Only top voted, non community-wiki answers of a minimum length are eligible