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

[Daniel Kiper]

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...

Daniel