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 <developm...@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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel