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

[Daniel Kiper]

On Wed, Mar 15, 2023 at 03:11:05AM +0000, Glenn Washburn wrote:
> 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

Modulo silent boot... I hope Robbie help us to define how exactly it
should work.

> understanding that I should not disable the gdbinfo command in lockdown
> mode, correct?

Yep!

Daniel