CVE-2008-3896 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3896): Grub Legacy 0.97 and earlier stores pre-boot authentication passwords in the BIOS Keyboard buffer and does not clear this buffer before and after use, which allows local users to obtain sensitive information by reading the physical memory locations associated with this buffer.
http://www.gnu.org/software/grub/grub-legacy.en.html GRUB Legacy is not actively developed any longer. Only bugfixes will be made so that we can continue using GRUB Legacy until GRUB 2 becomes stable enough. If you want more features in GRUB, it is a waste of time to work on GRUB Legacy, because we never accept any new feature. Instead, it is better to take part in the development of GRUB 2.
I got an answer: fzielcke@z-51.de wrote: "Hi, there's no official fix for this and I doubt that there'll be ever one. grub-legacy isn't maintained anymore. If grub2 gets support for this password thing then the one implementing it should take care of this." Well - grub 2 isn't out, but we've got 1.96 in the tree...
I got another mail, this time from chaac@nic.fi: "Hi Craig, a) No-one is really working on grub legacy. b) The details? If it is previous "hack" to modify grub or bios in order attack vector to be usable, we do not really see this as a grub problem as grub and bios is not then in authentic state and that problem needs completely different protection. If it is about password visible in memory; in most OSes you require root privileges in order to read memory so at that point the game is already lost as attacker can do anything anyway. I have nothing against clearing memory having the password input. But I do not see anyone making any changes to grub legacy. For grub 2 the story is completely different of course. Thanks, Vesa Jääskeläinen"
Since root privileges are required to see the password, and root could overwrite the boot loader anyway, no trust boundaries are crossed. Closing INVALID.
This is not about overwriting the bootloader. I hope I understood everything correct: When using full-hd-encryption, the pre-boot password should be used to decrypt the master key, and that decrypted key will be used by the OS to access the crypted data, the plaintext password should be deleted (overwritten) from memory. So this grub bug could lead to plain text password disclosure. Scenario: - Someone gets root access to your corporate ultra-secure server (which has full-hd-crypto & grub password protection) - he gets the plaintext password with the methods described in the preboot_whitepaper.pdf - he scans your network and uses that password to access other machines He could not have done that with the decrypted master key as it isn't the plaintext you enter at the preboot authentication prompt, neither with the grub password, because it is not saved on HD, there is only a MD5-hash on disk. Sure that's a bit unlikely; he could also modify the (pre)bootloader to store the password on HD, reboot the machine and wait for the sysadmin to enter the password but that would... a) be noticed immediately b) more much more complex than copying & pasting code from the preboot whitepaper I would have agreed to RESOLVED WONTFIX, but not to INVALID. ;)
(In reply to comment #5) > I would have agreed to RESOLVED WONTFIX, but not to INVALID. ;) I can see your point here, but you are screwed if someone gets root on a box anyway, and using the same password for different keys is not a good scheme to protect confidentiality either.