grub-devel
[Top][All Lists]
Advanced

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

Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms


From: Glenn Washburn
Subject: Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms
Date: Wed, 15 Mar 2023 03:11:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 3/13/23 12:27, Daniel Kiper wrote:
On Fri, Mar 10, 2023 at 03:27:13PM -0500, Peter Jones wrote:
On Thu, Mar 09, 2023 at 06:00:04PM -0500, Robbie Harwood wrote:
Glenn Washburn <development@efficientek.com> writes:
  2. Why should the load command not be printed when secure boot is enabled?
    * This was also requested by Daniel, I assume because of infomation leakage
      that may be a security concern.

I seem to have also missed Daniel's reply about this earlier, which was:

I think leaking info about the GRUB image addresses on the Secure
Boot enabled systems is not the best idea. Or do you think having
this feature enabled by default overweight potential dangers coming
from its misuse?

I don't know how these could help an attacker.  They'd need access to
console out to retrieve the values, and some way to send input... and
that's basically physical presence: at the very least, if they have
those, I imagine they'd just edit the menu entries, or drop to the grub
shell.

I'd like to also point out that we currently don't have anything like
ASLR in the pre-boot space, nor much hope of meaningfully getting it,
and typically have an identity memory mapped.  So, a serious attacker
can take a workflow like:

1) make a rough guess what kind of system they're attacking - vendor,
    product line, minimum memory size, etc.
2) get two or three similar machines on ebay
3) build a certificate chain that's got the exact same topology and cert
    sizes as the real one
4) enroll that the normal way
5) rebuild the grub binary with the "should we print this line" test
    inverted, so it's literally 1 bit different (i.e. jz -> jnz)
6) sign it
7) watch the load patterns on each of those machines and build a pretty
    simple model for candidate addresses
8) try them all when trying to exploit whatever bug they've found,
    either on individual attempts or possibly multiple at once if
    they're clever

If they're also using the shotgun method of identifying targets - i.e.
they've already used some other technique to get root on a bunch of
machines and now they're trying to escalate however many they can to
have Secure Boot breakouts - they're going to have a fair degree of
success with this method, and hiding the addresses will be an incredibly
minor speed bump for them.

I think worrying about exposing load addresses on the console with open
source firmware and no ASLR is not worth the trouble.

Good points! I was thinking about using lsefimmap to leak info about
memory usage. Of course this does not directly shows you GRUB memory
allocations but it is enough to infer them by comparison of lists of
memory regions with and without the GRUB. So, taking into account above
it looks printing the GRUB load address does not give potential attacker
much advantage and we can print the load address unconditionally. Until
I do not hear otherwise...

Ok, so I'm understanding that I can move the printing of the gdb command out of the !secureboot condition and have it always print. I'm also understanding that I should not disable the gdbinfo command in lockdown mode, correct?

Glenn



reply via email to

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