Recently, support for in-memory UEFI-capsule updates  was introduced to
the firmware framework coreboot [1]. The original implementation wasn't
accounting for potential integer overflows, which could be exploited by
an adversary with control over memory contents before a reboot. Because
early boot firmware often doesn't implement modern countermeasures, the
exploit I'm going to describe is rather simple. This highlights the im-
portance to avoid untrusted input in early boot stages altogether.

Note:  For readers who are generally familiar with exploits, this might
be a dull read.  The point of this post is primarily to show how easily
bugs can be exploited in unprotected, early boot code.

[1]: https://review.coreboot.org/c/coreboot/+/83422
     "drivers/efi/uefi_capsules.c: coalesce and store UEFI capsules"

Environment and Threat Model

A UEFI capsule is a data container passed to UEFI firmware. Usually, a capsule contains a firmware update, but it can also contain code to be run by the firmware. Sometimes, a capsule actually contains an update program, paired with the actual firmware update.

Read more...

During the last maybe 10 years of my open-source involvement, I have
seen a lot of conflicts. Some of them involving myself, some of them
I only witnessed, and some of them I helped to settle.  It was often
hard for me to look the other way. Trying to understand why, I star-
ted thinking about underdogs.  This is just me brooding, without any
conclusive thought.

What do I call an underdog? To me it’s just somebody who may feel or is left alone in an argument against all other involved people. Having been too often in such a situation myself, I know it can take a huge emotional toll.

Read more...