You are not logged in.
I just compared the swapfiles from ArchLinux, Windows 10 and OS-X Sierra.
Only on Linux it was possible to access many online and system passwords in plaintext.
dd if=/dev/sdxx of=swapfile.bin; strings swapfile.bin
.
I could not detect which applications are responsible for this behavior (Most likely a web browser and a desktop manager).
The Windows files (page.sys, hibernate.sys, swapfile.sys) allowed only the recovery of documents and browser histories but not the passwords.
OS-X (/private/var/vm/swapfileX) files are encrypted and protected.
Should be the use of unencrypted swapfiles be explicitly discouraged in the documentation/Wiki ?
Offline
Which device did you use the dd command on?
On Linux, many passwords are saved in plaintext, for example: netrc, mail related stuff etc. But, only you can tell which passwords were you able to extract and whether you had any software installed which made use of those.
Offline
Which device did you use the dd command on?
On Linux, many passwords are saved in plaintext, for example: netrc, mail related stuff etc. But, only you can tell which passwords were you able to extract and whether you had any software installed which made use of those.
I used age-old HDDs for all three OSes and did not enable disk encryption for any of them. I booted from an USB stick (Linux and OS-X with UEFI and Windows 10 with BIOS). I used dd To copy the Linux swap partition to a file.
The file begins with:
SWAPSPACE2# This is private data. Do not parse
PRIORITY=30
LEVEL_PREFIX=1
FORWARD_TO_SYSLOG=0
FORWARD_TO_KMSG=0
FORWARD_TO_CONSOLE=0
IDENTIFIER=systemd-udevd
UNIT=systemd-udevd.service
# This is private data. Do not parse
..
Later on I found session descriptors:
[Scope]
Slice=user-1000.slice
[Unit]
Description=Session c2 of user yousry
[Unit]
After=systemd-logind.service
[Unit]
After=systemd-user-sessions.service
[Scope]
SendSIGHUP=yes
[Scope]
TasksMax=infinity
# This is private data. Do not parse
Than it got very easy to extract the passwords. For Example:
/org/gnome/DisplayManager/Session
AnswerQuery
org.gnome.DisplayManager.UserVerifier
gdm-password
*** REMOVED CLEARTEXT PASSWORD ***
I think it is not very complicated to deduce a connection between application, user and password.
Last edited by yousry (2017-01-16 12:57:33)
Offline
/org/gnome/DisplayManager/Session AnswerQuery org.gnome.DisplayManager.UserVerifier gdm-password *** REMOVED CLEARTEXT PASSWORD ***
I think it is not very complicated to deduce a connection between application, user and password.
This is probably gnome-keyring doing its thing. Again, it has to decrypt passwords before being able to use them. It does so in the RAM and in case of low memory situations it probably gets swapped as well. I guess, it makes sense to encrypt your swap partition depending on your threat model.
Offline
yousry wrote:/org/gnome/DisplayManager/Session AnswerQuery org.gnome.DisplayManager.UserVerifier gdm-password *** REMOVED CLEARTEXT PASSWORD ***
I think it is not very complicated to deduce a connection between application, user and password.
This is probably gnome-keyring doing its thing. Again, it has to decrypt passwords before being able to use them. It does so in the RAM and in case of low memory situations it probably gets swapped as well. I guess, it makes sense to encrypt your swap partition depending on your threat model.
Yes, this was a big moment of surprise that gdm doesn't use mlock (prevents swapping) and ZEROing for the password handling . However, it would be a cumbersome task to find every case where passwords can be stored unencrypted to disk and file a bug report for it. (As I said earlier, I also found my online passwords in the swapfile).
I just tried present my findings in a direct comparison between different OSes; and Archlinux has a security disadvantage with its default (recommended) setup.
Offline
However, it would be a cumbersome task to find every case where passwords can be stored unencrypted to disk and file a bug report for it. (As I said earlier, I also found my online passwords in the swapfile).
I'm afraid recommending a safer swap setting will encourage developers to care even less about security aspects of their software, because it's easier to blame the user for not reading the Arch bbs than it is to write clean code.
Offline