Vincent Danen wrote:
* [2008-07-29 10:01:45 -0700] Mike Hamburg wrote:
On Jul 29, 2008, at 5:45 AM, Jonathan Brossard wrote:
1) Plain text password disclosure.
Required privileges to perform this operation are OS dependant,
from unprivileged users under Windows (any), to root under most Unix.
2) A privileged attacker able to write to the MBR and knowing the
password
(for instance thanks to 1), is able to reboot the computer in spite
of the
password prompted at boot time by initializing the Bios keybaord
buffer with
the correct password (using a second bootloader that will in turn run
lilo).
--[ A bit more details :
On x86 computers, Grub relies on BIOS interrupts to read user passwords.
This API relies on an internal BIOS Keyboard buffer in the BIOS Data
Area,
which is not sanitized before and after use.
This allows a loged in user to potentially retreive the password in
plain text
(the level of privileges required to perform this activity can be as
low as an
unprivileged guest user under Windows - from 9x to Vista).
Since the BIOS keyboard buffer is also not initialized before use, an
attacker can
fill it up using a rogue bootloader and then load grub, allowing him
to reboot the
computer without having physical access to the computer, resulting in
a full security
bypass of the Grub password authentication.
While #1 seems like a real problem to me, particularly on Windows, I'm
having trouble
understanding the security implication of #2. If the attacker can run
a rogue bootloader
before GRUB, can't he boot your machine anyway? What stops him from
running an evil
fork of GRUB that just doesn't check boot passwords?
Don't forget that if he has the capability to do that, he can just edit
menu.lst and remove the password entirely, or set a new one.
Hi All,
From point of view of GRUB Legacy, memory where password is handled
could be cleared. But any other than that I do not think it is really a
GRUB issue. If there is write access to GRUB configuration file/Any used
firmware/BIOS/MBR/other GRUB files then the whole thing is lost already.
Attack vector for keyboard based input could be easily enhanced to
overcome any "security" vector to put in place while at same time making
it harder for normal user to use it.
For GRUB 2 this is not issue at the moment as it does not yet feature
official mainline support for password protection (authentication
support is still in the oven).
Is there something I am missing in here?
Thanks,
Vesa Jääskeläinen
_______________________________________________
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub