[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vendor-sec] Re: [Fwd: Vulnerabilities in Lilo 22.6.1 and previous v

From: Vesa Jääskeläinen
Subject: Re: [vendor-sec] Re: [Fwd: Vulnerabilities in Lilo 22.6.1 and previous versions]
Date: Tue, 05 Aug 2008 09:49:16 +0300
User-agent: Thunderbird (Windows/20080708)

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?

Vesa Jääskeläinen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]