Re: Vulnerability in Software Suspend 2 (all versions)

Jonathan Brossard
2008-08-18T07:01:49Z

[-- Attachment #1: Type: text/plain, Size: 6124 bytes --]

>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@m4x.org 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@tuxonice.net. For swsusp and uswsusp
>>>>> (which would have the same problem), refer to linux-pm@lists.osdl.org.
>>>>>
>>>>>
>>>> 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@m4x.org
>
>

--
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 #2: whitepaper.pdf --]
[-- Type: application/pdf, Size: 1939749 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]