>Password retrieved from RAM is a well known issue :)No, it is a Bios problem, and most manufacturers are vulnerable, so it is definitly not a "well known issue". We are not talking about a typical userland application using
a weak primitive like getpassword() here, but of a misusage of the BIOS Api. (cf attached whitepaper for information).Anyway, I agree the problem doesnt lie in your software but in the swap encryption like Nigel mentioned. If you could help me track which versions of the kernel using dm-crypt
were vulnerable, that would help me a lot. Regards, Jonathan- florent.chabaud@xxxxxxx wrote:
Dear Jonathan, Sorry for intervening so lately, but Nigel is right : those adresses are really out of date ;-) Le 28 jui, Jonathan Brossard a écrit :Dear Nigel, Feel free to put me in my place if I am wrong here : When you try to boot a tuxonice capable computer and restore the state of the computer using a hibernation file... you are asked for a password, which is not the standard userlandlogin prompt (for a imple reason : there is no kernel in memory at that time).That password is part of tux on ice, right ?AFAIK this is not part of swsusp nor tuxonice. I'm still using swsusp, although not contributing any more, and I don't have any password to type in my configuration. xxd -l 32 -s 0x041e /dev/mem 000041e: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000042e: 0000 0000 0000 0000 0000 0000 0000 0000 ................Well, that password can be retreived from RAM !Password retrieved from RAM is a well known issue :) From your description, you seem to say that the kernel is not running at the time you seize the password. This indicates for sure that tuxonice is not involved, since it is part of kernel. The way tuxonice works is launching the kernel as usual and interrupt normal boot as soon aspossible if a frozen image is detected.What you may have in your case is either a hardware password, managed by the BIOS, or a password used to encrypt swap (and swsusp image) as described in swsusp-dmcrypt.txt. Now, I agree with Nigel that this is not part of swsusp, but it may be a bug in the configuration of dmcrypt. You should also note that from a security point of view, the security model is not at all circumvented. You need to have a root access to /dev/mem from a resumed session, to obtain the password, and even if the password was erased (which should be done anyway, it's a good practice)you still have the ciphering key of the swap somewhere in memory.Anyway, thank you for the report. Please feel free to exchange more information in order to identify more precisely the problem, and specially the configuration you use. Sincerely yours,Florent ChabaudBest regards, Jonathan- Nigel Cunningham wrote:Hi again. On Mon, 2008-07-28 at 14:20 +0530, Jonathan Brossard wrote:Dear Nigel,This is not a bug in TuxOnIce (or for that matter other Linux hibernation implementations, which would have the same issue).Yes it is.TuxOnIce has no way to know what running applications have passwords stored in memory or whether they are storing them in an encrypted format or not. Bugs should be filed against applications that are storing passwords in plain text.We are talking about the password of tuxonice itself here...TuxOnIce itself doesn't have any password support. Do you mean a password for encrypted swap or such like?Please boot a computer using tuxonice, go for hibernation, reboot, and then type this (as root) : xxd -l 32 -s 0x041e /dev/memBy the way, these contact email addresses are grossly out of date. For TuxOnIce, the contact is nigel@xxxxxxxxxxxxx For swsusp and uswsusp (which would have the same problem), refer to linux-pm@xxxxxxxxxxxxxxxI did my best to find one on the site's website and ended up taking those of sourceforge.Hmm, you're right there. I'll address that shortly. Regards, Nigel-- Jonathan Brossard Security Research Engineer iViZ Techno Solutions Pvt. Ltd. Mobile: +91-9748772994 Kolkata: iViZ Technolgy Solutions(P) Ltd c/o Erevmax Technologies (P) Ltd DLF IT Park, Tower-1, 12th Floor 08 Major Arterial Road New Town, Rajarhat Kolkata- 700 156 Kharagpur: iViZ Techno Solutions Pvt Ltd, School of Information Technology, Indian Institute of Technology, 2nd Floor, Takshashila, Kharagpur 721302 West Bengal, India. Phone: +91-3222-282300 ext 4324 Web page: http://www.ivizindia.comFlorent Chabaud gpg: 28C9 9E1A 5507 5574 EDE6 2E8F 2B37 D83F 95C8 1C3C http://www.carva.org/florent.chabaud | florent.chabaud@xxxxxxx
-- Jonathan Brossard Security Research Engineer iViZ Techno Solutions Pvt. Ltd. Mobile: +91-9748772994 Kolkata: iViZ Technolgy Solutions(P) Ltd c/o Erevmax Technologies (P) Ltd DLF IT Park, Tower-1, 12th Floor 08 Major Arterial Road New Town, Rajarhat Kolkata- 700 156 Kharagpur: iViZ Techno Solutions Pvt Ltd, School of Information Technology, Indian Institute of Technology, 2nd Floor, Takshashila, Kharagpur 721302 West Bengal, India. Phone: +91-3222-282300 ext 4324 Web page: http://www.ivizindia.com
Attachment:
whitepaper.pdf
Description: Adobe PDF document
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
