Re: Vulnerability in Software Suspend 2 (all versions)

["Jonathan Brossard" <jonathan@xxxxxxxxxxxxxxxxxxxxxxx>]

Dear Florent and Nigel,

I agree the problem lies in the dmcrypt module, but I couldn't replicate the bug on the latest kernels (I know 2.6.16 was vulnerable, so something must have been patched in the meantime). I am in Defcon right now and will try to verify those assumptions sometime next week.

The problem might be known or whatever, but most disk encryption software are affected. I had lunch with the Bitlocker team from Microsoft today itself, and they find the bug amazing... so maybe you'd like to have a look at my paper sometime (I can leak it to you if you want, or just ask Nigel).

Regarding the addresses, you might want to update the sourceforge page, this is the first place where ppl look for project mainteners...

Thanks for your reply,
Best regards,

Jonathan-

On Sat, Aug 9, 2008 at 7:19 PM, <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 userland
> login 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 as
possible 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 Chabaud

>
> Best 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/mem
>>>
>>>
>>>
>>>> By the way, these contact email addresses are grossly out of date. For
>>>> TuxOnIce, the contact is nigel@xxxxxxxxxxxx. For swsusp and uswsusp
>>>> (which would have the same problem), refer to linux-pm@xxxxxxxxxxxxxx.
>>>>
>>> I 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.com
>

Florent 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

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm