|Re: [Hangout-NYLXS] GRUB Vulnerability
|I understand what is being ping-ponged here in terms of information and yes, it is all true as each is being a facet of a larger gem.
But the point is this - to access this vulnerability one has to be at a keyboard connected physically to the machine and press backspace 28-times. Is this correct? So how is it a vulnerability when there is no keyboard and there is no physical access to the machine?
Let get as dumb as possible to get the lowest level of information here. GRUB is - what? A Boot Strap Loader? When the machine is turned on and the bootstrap loader kicks in, when can you press backspace 28 times? When it pops up a menu for which Linux slice to boot from? For me I have that menu timed for 1 second before it goes to the default Linux slice.
When I was the CTO of BizinfoPlus, our servers were at TelX, a fine little dat-warehouse on Houston Street at the old Western Union telegraph building. Our servers were in a combination locked cabinet and when you open it, there was not display or keyboard tray among the servers. And I glued plastic covers on the USB and Display ports. So that eliminated that threat. When I need access, I went there and connected to the servers remotely with my laptop through the direct network class - as I programmed remote access to be done through a direct network access and not through another connected network. In fact, I had remote access to the server to be done through a very specific IP Address of that network. So that eliminated another threat.
When I saw a security hole, digital or physical, I tried to plug it up. I'm not saying that I'm one of the best out there because there are thousands out there that are better than I.
But one day, BizInfoPlus went down. could not explain why. When I got there a couple hours later, the servers were back online. At the time I did not go through the logs. But then it happened again and again. And all within a specific time of day on certain days. The logs were stating that power was cut off on the servers. Why? I though that maybe one of our back up batteries was shorting out, but Telx has its own back ups of batteries and generators and my batteries checked out bad for some reason. So I decided go there on one of those specific time/days. I went in early and connected, opened the cabinet and connected the laptop.
A 1/2 hour later, some young custodian came in with a ladder and a floor polisher. You can guess the rest. Sine the cabinets were lined up in aisles, he went behind the row my cabinet was in, put the ladder against my cabinet, climbed up and reached up to a power junction and disconnected my cabinet's plugs and plugged in his floor polisher. I went through the roof! I yelled at him so loud that my voice echoed through TelX's floors and the systems admins from other sites and TelX's own admins, along with security guards came running. And they saw it - my cabinet unplugged and this idiot setting up his floor polisher. This Idiot DOS'ed our servers by actually unplugging it from its power source for so many times that he crapped out our back up batteries! And we were not the only ones he was doing this too, from the count many other company techs physically being there to see what was going on!
Eventually he was fired. And my friend threatened to sue but settled out of court.
So... GRUB does not give you network access at boot time so you can't get in through a network. You have to be there with a keyboard connected to the machine to circumvent it. The Security flaw is not within GRUB itself, It is with having physical access to the machine from LACK OF SECURITY on the Physical Level! If you eliminate the physical security hole, then what vulnerability is there? Like stated, if there is physical access to the machines, then where is your security? Your machines and/or their drives can be take away and then they can take their time cracking your encryption.
On Sun, 12/27/15, Chris Knadle wrote:
Subject: Re: [Hangout-NYLXS] GRUB Vulnerability
Date: Sunday, December 27, 2015, 3:43 AM
> On 12/26/2015 09:10 PM, Chris Knadle
>> Rick Moen:
>>> Quoting Chris Knadle (Chris.Knadle-at-coredump.us):
Thus... it's "not news" to those not running
full disk encryption.
>>> It's also 'not news'
to those who assume unrestricted access to the
>>> physical console and system box so
approximates total absence of
security as makes little diference.
>> Okay -- walk
me through the logic you've stated above. There's
a machine in
>> front of you that is
using full disk encryption including /boot and the
>> machine boots to a GRUB password
prompt. Please explain how this situation
>> "approximates total absence of
>> -- Chris
> Umm - maybe you can pull the hard drive
out and crack it at your leisure
boot with a different drive? think the encrypted drives
> Snodens data from the
> I know
this is old fashioned of me, but how can you think you have
> security if you don't have
physical security of the device?
There's a chance we might be talking about
different meanings of "security"
-- in this case I'm talking about securing
the data, i.e. the contents of a
using full disk encryption (in relation to GRUB).
Having physical access to the
drive doesn't automatically let you crack it
open like a Piñata and get the encrypted data
within -- that's exceptionally
difficult. In fact physical access of a
machine that's off is one of the
"threat models" that full disk
encryption is relatively good for -- say like
a laptop or a backup tape drive being taken
after being accidentally left
Full disk encryption actually
works, so if the data is decrypted the typical
way that's done is by /bypassing/ the
encryption rather than brute-forcing
getting the owner to give up the password, getting it via a
logger, pulling RAM out of the machine
and freezing it long enough to read
memory and getting an input password that way, catching the
unawares while using the machine (like
what happened with Silk Road), etc.
is another reason to keep in mind what your "threat
model" is --
looking to defend against.
Where this applies to GRUB: it's possible
to set up GRUB so that the
can be passed onto a GRUB module and decrypt the full
encryption so that there's just one
password to enter at boot time.
> I think we are somehow miscommunicating,
as I wasn't addressing the
of using full disk encryption.
hangout mailing list
hangout mailing list