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
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.
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.
> 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