10

The post How to find passwords in memory (password managers) concluded, that passwords are visible in plaintext if you login to a website. Password managers tend to store the passwords encrypted in memory, but they need to decrypt them in order to sign in.

A memory dump requires, that the targeted machine is running and the victim logs in to an account. The password could be exposed in plaintext and a memory dump could be created (with a cold boot attack or somehow else).

But what about swap? It is usually used, if the RAM runs out of capacity and the memory gets outsourced to disc. The outsourced capacities could contain an unencrypted password, that will be stored "persistently" on disk until it will be overwritten. With a bit of luck, an attacker could analyze the swap of a computer later without the requirement, that the target uses the computer.

So, is a swap vulnerable to this kind of attack?

After reading the answers I did a bit of further research and found a similar post on Askubuntu which suggests to encrypt the swap partition. This should avoid the problems around leaked information in swap memory.

user3147268
  • 735
  • 6
  • 13
  • 4
    Usually you store passwords (and cryptographic keys) in memory and tell the OS not to swap out this memory section to prevent this exact leak. So the OS will swap out unimportant stuff (swappable memory areas) and at the end the unswappable user memory (kernel memory has priority for not being swapped out) – SEJPM Aug 10 '15 at 08:16
  • Thanks for your answer. This concept of allowing the swap or not makes sense. – user3147268 Aug 10 '15 at 08:43
  • The thing here is, if you use an offline password manager, then be sure you cannot be shoulder surfed. If you use an online local password manager,then you'll face the problems of writing to swap or memory. – munchkin Aug 10 '15 at 15:53
  • Good operating systems encrypt their swap. Hell, even Windows can do it nowadays... To be honest, anything less than full disk encryption in 2015 is incredibly naive. – Bruno Rohée Aug 11 '15 at 00:39
  • I never ran out of RAM with 8GB even with 40 tabs on chrome, multiple applications opened , 2 VM's running and more i can't remember. So i think swap is rarely used at all in high end machines – Freedo Aug 12 '15 at 11:37

2 Answers2

6

As I've already pointed out in my previous comment, this attack has been foreseen and already countered (by most cryptography using applications).

The way you do this is, you (the developer) tell the operating system (OS) not to swap out this particular section of the memory. The OS will usually honor that and "make a note" somewhere in the memory manager not to swap this out. However even this marked area may get swapped out (if too much data is declared "unswappable" or a kernel-mode program needs "too much" memory) so it's better than doing nothing (and letting it be unswappable) but still not perfect and tells you not to flag everything unswappable.

As you're concerned about swapping out secret data to disk you may also be concerned about the hibernation state many OSs offer, where you actually write the full current RAM to disk so you can boot up faster at a later point and can resume your work. This attack scenario is less commonly considered but should be countered by careful treatment (-> erase all cleartext keys / passwords on hibernation / shutdown) and appropriate data encryption.

As asked in the comments to the other question I'll also quickly provide (some) overview of where to check if the used (open-source) program is vulnerable.

Windows: You need to inspect the memory (password managing) portion of the code and specifically look for VirtualLock() and VirtualUnlock

Unix-like systems: Inspect the same portion of the code as for Windows but now look out for mlock() and munlock(). Also look for mlockall() at any time in the code as this globally locks the memory into RAM.

SEJPM
  • 9,500
  • 5
  • 35
  • 66
  • Will it actually get swapped out even if it is mlocked? I thought it would eventually just kick the OOM killer. According to the manpage for `mlock(2)`: `all pages that contain a part of the specified address range are guaranteed to be resident in RAM [...] until later unlocked`. See also the [POSIX specification](http://pubs.opengroup.org/onlinepubs/009695399/functions/mlock.html). In the Linux kernel, it sets (struct struct mm_struct *)mm->locked_vm, and it looks like `mm/swap.c` checks for that before adding something to the evictable list. – forest Dec 30 '17 at 03:55
1

You are correct about this assumption: an attacker could analyze the swap of a hard disk looking for the passwords. It is for this reason that decently-written password managers make sure that the password is always kept in RAM and never swapped on virtual memory.

dr_
  • 5,060
  • 4
  • 19
  • 30
  • If you happen to know how they can obtain such an assurance (on both *NIX/Win), and how users can possibly verify that a (open-source) password manager correctly prevents passwords from being swapped, it'd be a useful addition to your answer and would help fellow developers understand how to avoid this issue in their code :-) – Steve Dodier-Lazaro Aug 10 '15 at 13:07