8

A lot of the news regarding the Meltdown vulnerability is emphasizing that it allows programs to read memory that should be off limits to the user. While I understand that this should not happen, few sources have explained exactly how accessing kernel memory is dangerous.

What information is stored in kernel memory? What would being able to access, but not modify, kernel memory allow an attacker to do?

Rob Rose
  • 223
  • 1
  • 7

3 Answers3

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 physical addressing, if your program reads a byte from address 17, it's reading from the same set of eight memory cells each time. Turns out, a "physical-only" way of addressing memory rather limits what you can do, particularly with regards to running multiple programs at once.

Enter "virtual addressing". Now, your program's "memory address 17" no longer corresponds to a specific part of physical memory. Instead, when the CPU wants the data from that address, it asks a component called the "memory management unit" (MMU) which, in cooperation with the operating system, figures out how to fulfill that request.

This permits a number of efficiency and capability gains. The best known is probably "swap", commonly known as "virtual memory": address 17 might be temporarily stored on disk, and your program's request is put on hold while the OS stores the contents of part of physical memory to disk, and then loads the piece that your program thinks of as "address 17". Since the range of available virtual addresses is typically much larger than the amount of physical memory, this lets the OS give the appearance of a computer with far more RAM than it actually has.

The biggest gain from virtual addressing, though, is also entirely hidden from the typical user: it lets the OS give each program the illusion that it's the only program running on the computer. Your program's "address 17" isn't the same piece of memory as some other program's "address 17". This means that programs don't need to worry about hiding secrets from each other: Javascript running in your web browser, for example, can't read the contents of your password manager's memory.

For efficiency reasons, the Linux kernel assigns half the available virtual addresses to itself in each program's view of memory, and assigns all of physical memory as part of that address range (the Windows kernel does similar things, though the details vary). This lets the kernel access anything it needs to without having to adjust the MMU. The kernel then protects its address space so that an ordinary program trying to read the memory will crash.

Enter Meltdown: it lets a program indirectly read kernel memory without crashing. It's much slower than direct reading (typically around 150 kilobytes per second, where direct reading is measured in gigabytes per second), but it bypasses the protection. Because all of physical memory is mapped into the kernel's address space, an attacker employing Meltdown can break the "I'm the only program" illusion.

An ordinary desktop user doesn't have many programs that need to keep secrets from each other, and doesn't run much untrusted code -- the only major threat from Meltdown is hostile Javascript reading the contents of their password manager, and the details of how Meltdown works make it hard to use from Javascript.

The big threat from Meltdown is to cloud and shared-hosting providers. These computers routinely run programs from untrusted users, and depend on the "I'm the only user" illusion to keep things safe. Meltdown lets an attacker with an account break this illusion, and do things like steal other users' SSL private keys, usernames and passwords, payment-processing credentials, and other sensitive information.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 1
    appears to miss the actual question of why reading the KERNEL memory is harmful. the examples of stealing other user passwords and data are all USER memory. – szulat Jan 08 '18 at 01:30
  • @szulat, as I mention, kernel memory provides a window into pieces of user memory that a program isn't supposed to be able to see. – Mark Jan 08 '18 at 02:02
  • 1
    ok, I see... so maybe the answer should be just “kernel memory in the context of meltdown is whatever memory mapped for use by kernel and not normally available for the current user, which can be most of the physical memory. that’s why it is dangerous.” In other words, the question seems to arise from the inadequate definition of the kernel memory. – szulat Jan 08 '18 at 03:01
  • How does Meltdown differ than Spectre then? Wouldn't Spectre also allow an adversary to break the "I'm the only program" illusion? Or is the difference that Meltdown would allow an adversary to read the memory in a different VM, while Spectre would be limited to reading memory allocated to other programs within a VM? – Rob Rose Jan 15 '18 at 17:17
  • 1
    @RobRose, the big differences are in technique and what can be accessed. Meltdown straight-out asks for the contents of protected memory, can access anything the kernel can access, but can't reach memory that's been swapped out to disk. Spectre indirectly forces another program to access memory, and can only access parts of memory that the other program can access, but can theoretically access memory that's been swapped to disk (though I suspect timing problems will keep this from being possible in practice). – Mark Jan 15 '18 at 19:00
  • 1
    @RobRose, in terms of virtualization, it's the other way around: Spectre can break out of virtual machines, while Meltdown can only read memory the virtual machine's kernel can read; it can't read the host kernel's memory. Both attacks can break out of sandboxes and containers, since those have a single kernel that's shared across all instances. – Mark Jan 15 '18 at 19:03
-1

For example, you could read the ssh private key of the system, or any number of other protected resources.

mricon
  • 6,238
  • 22
  • 27
  • 1
    SSH keys are not in kernel memory. – Gilles 'SO- stop being evil' Jan 07 '18 at 19:57
  • 1
    You were asking about Meltdown and how it impacts kernel-managed memory. I think you misunderstand what "kernel memory" implies here: it's not memory taken up by the kernel, but virtual memory managed by the kernel. If you read the [bug description](https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html) you'll see that it allows, "(at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts." – mricon Jan 07 '18 at 21:48
  • This question asks about reading kernel memory, not about the broader impact of Meltdown. Not everybody agrees on terminology, but “kernel memory” definitely excludes the memory of other processes, it is not all “virtual memory managed by the kernel”. – Gilles 'SO- stop being evil' Jan 07 '18 at 22:12
  • 1
    "Kernel memory" is all of the system's physical memory. – mricon Jan 07 '18 at 22:19
  • No, that makes absolutely no sense. Process memory is not kernel memory, that's the whole point of calling it “kernel memory”. Note that there is a nuance between “kernel memory” and “memory mapped by the kernel” — the kernel also maps process memory. This nuance is important to understanding the impact of Meltdown. [Mark's answer](https://security.stackexchange.com/a/176990) explains it in passing. – Gilles 'SO- stop being evil' Jan 07 '18 at 22:47
-2

It all depends on what kind of system we are talking about.

Nothing will happen if you don't have malware on your computer. If you are using your desktop or laptop as the single user, and you have malware, you have lost. Without any access to kernel memory. Because that malware can read the files on your hard drive, it can find out everything about the single user.

But on a server, if there is malware "on the computer", it's actually only installed for one user. That user has lost. But the 100 other users on the same server should be safe. Now if you can access kernel memory, then you can figure out ways how to attack the other 100 users on the server.

gnasher729
  • 1,823
  • 10
  • 14