Bug 87580

Summary: KDE does not mlock sensitive data (password)
Product: [Unmaintained] kdm Reporter: Casteyde.Christian <casteyde.christian>
Component: generalAssignee: kdm bugs tracker <kdm-bugs-null>
Status: RESOLVED INTENTIONAL    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Sample of mlock/munlock

Description Casteyde.Christian 2004-08-20 10:54:05 UTC 
Version:           inconnu (using KDE 3.2.3, compiled sources)
Compiler:          gcc version 3.3.4
OS:                Linux (i586) release 2.6.8

This is a serious security report. Please take into account.

Security applications should mlock memory where sensitive data, such as passwords, reside. If they fork and do not exec, they also should clear these data because child process do not inherit memory locks. Unused sensitive data should also be cleared if not necessary, to prevent debugging / kernel memory peaking from revealing these datas.

Not doing so will eventually leave these datas on swap file, and remain accessible long after the application closed. That is:
- if an attackant get root access, he can also get clear text password for virtually all users (by reading /proc/kcore) ;
- if the machine is stolen / public access, passwords can be retrieved from swap partitions after booting on a rescue CD. This one is critical.

Standard login doesn't free its memory, but it mlock it, therefore we cannot get passwords on swap. However, ALL KDE applications seem to ignore this problem (kdm especially, didn't check gdm / xdm), and certainly kwallet and Konqueror web forms (didn't checked either).

To see the problem, do a small memory hog programm, log in, start this memory so that kdm memory will get swapped, log in as root, and do the following:

strings -a /dev/myswapdev > /a.txt
grep "MyPassword" /a.txt

and you will get the password, which should NEVER happens.

I didn't checked KDE 3.3.0.

Regards,
C. Casteyde
Comment 1 Casteyde.Christian 2004-08-20 11:32:31 UTC 
Created attachment 7192 [details]
Sample of mlock/munlock

I forget to tell that zeroing the buffer after use is not safe either.
A the process can be swapped with the sensitive data before buffer is
overwritten, and overwriting it after that does not necessarily zero
the swap area where they are stored. mlock should **really** be used.

Please also note that munlock may unlock more than what we would expect
at first glance, since VMM works on a page basis. Therefore, security
buffers should page aligned and page multiple sized.

Finally, mlock requires root privilege (OK for kdm, but not for
kwallet/konqueror/kmail). Therefore, a password daemon should be
implemented (if not yet). PAM could be used for this, but PAM is NOT
a requirement of KDE (for instance Slackware does not use it, this is
a slack security issue for me), and wouldn't be usefull for non system
passwords.
Attached a sample of mlock / memset / munlock use.
Comment 2 Oswald Buddenhagen 2004-11-05 15:55:57 UTC 
this is a pretty much pointless exercise. if the machine is cracked or your root is an asshole, you're screwed anyway. and if you want your mobile device protected, use a cryptoloop. why would somebody be interested in a password of a system he has hardware-level access to, anyway?
the password daemon idea does not help in many/most cases, as the password just has to be transferred in plain. and the applications for a purely yes/no-answering daemon are quite limited; in fact the only application coming to my mind is the screen saver ... or do you know more users of kcheckpass?
lack of mlocking is not fixable with PAM-based setups anyway (unless one'd mlock the entire address space).
and just to dwarf your ideas entirely ... your example program is not safe, either: fgets can/does have an own buffer at the stdio level.
Comment 3 Casteyde.Christian 2004-11-05 19:23:49 UTC 
> this is a pretty much pointless exercise. if the machine is cracked or your
> root is an asshole, you're screwed anyway. and if you want your mobile
I do not want to protect memory for such a case. I thought the computer/disk
could be stolen / public access. In such a case, the fact that plain data are stored on the device is a real security problem, when we *could* only store
crypted data (or even better store nothing at all). If I had to accept your argument, I would say using shadow password and crypting passwords with salt instead of storing them in plain text would be useless, since a simple chmod 600 is secure enough...

> device protected, use a cryptoloop. why would somebody be interested in a
Finally, I used dmcrypt. Nevertheless, the problem is still there to my mind.

> password of a system he has hardware-level access to, anyway? the password
that would at least leave time enough to change all passwords, before he manages to brute force crack the crypted pwd / data and get access to other systems.

> mlocking is not fixable with PAM-based setups anyway (unless one'd mlock
> the entire address space). and just to dwarf your ideas entirely ... your
No. Each level has to mlock its sensitive data. PAM is unsecure too.
I didn't said it was a KDE only problem. However, it's true that modifying KDE is not very usefull until all low level layers are fixed.

> example program is not safe, either: fgets can/does have an own buffer at
> the stdio level.
True. That was only a sample.

Anyway, I can understand you don't have time to fix this (as well as developpers of related software, even if I think at least PAM and login could and should be fixed first because these *are* supposed to be secured).

CC