Re: Rescatux 0.41b1 released with UEFI rescue options
On 04/22/2017 02:25 PM, adrian15 wrote:
> Hi Debian-efi list,
> Last week I released Rescatux 0.41b1 with a bunch of new UEFI rescue
> options. I just wanted to share with you some technical details about
> those options so that I can get some feedback from you.
Any feedback is welcome.
> Thank you for any feedback you can give me back!
Nice to see more pre-boot diagnostics available! Here are a few things
I'd like to see in a Rescatux (or inside D-I for that matter):
1) Have boot option to boot into UEFI shell.
Instead of only booting into Rescatux Linux, have a boot option to boot
into UEFI Shell. Include the UEFI Shell on your boot image. ALT Linux
Rescue does this -- or at least supposedly, it hasn't worked for me. It
is a nice option if you need to manually run a UEFI Shell app -- a
firmware update from a vendor, etc. Similar to the need to occasionally
run a shell from inside an OS installer. In addition to UEFI Shell and
full set of shell commands, also include CPython for UEFI and CHIPSEC
for UEFI (see next item). With CPython installed, also have an option to
jump into Python shell, that'll be more familiar to some than the UEFI
2) Have a mode to let users run CHIPSEC.
2a) Have a boot mode that enables root Linux shell with CHIPSEC
installed, so user can run appropriate CHIPSEC commands.
2b) Have a boot mode that lets user boot into the UEFI Shell with
CHIPSEC installed, so user can run appropriate CHIPSEC commands.
Both the OS-present Linux version as well as the UEFI Shell version of
CHIPSEC would be useful to have, at times they have slightly different
abilities.) For example, you need to dump PCI option roms at boot-time,
not after OS is loaded.
CHIPSEC is the only firmware vulnerability scanner around, and AFAIK it
is the larger OSS project without mainstream packaging, due to concern
of the CHIPSEC kernel driver having lots of access and little to control
it, see the WARNING.txt in the CHIPSEC code for more details. However,
since that warning, CHIPSEC has gotten the ability to run a subset of
it's abilities withOUT the driver being loaded, which is not reflected
in that warning.
Today, CHIPSEC installs via Python's PIP installer (which calls 'make'
to build/install a kernel driver, in addition to the Python
installation). There is current Debian packaging for CHIPSEC under way,
see CHIPSEC github code.
One way to reduce impact of CHIPSEC misuse by attacker is to scope it's
use, not keeping the driver running, is to have it as a menu optin in a
rescue distro. IMO, having CHIPSEC available in a rescue distro is ideal
for that audience. Rescuing broken systems aside, this would add a new
use for Rescatux, analyzing new (or used) systems for security profile.
Intel (now McAfee) CHIPSEC team also likes idea of putting CHIPSEC as a
menu option in D-I, which is similar to a rescue distro menu entry.
Today, CHIPSEC is run by Linux UEFI Validation's LUV-live, but in batch
mode, and you have to manually go view a logfile after all the batched
tests are done. While this is useful, an interactive use of CHIPSEC's
security tests would be immediately useful (and interactive use lends to
colorized output, so you can better see the red failures, than in a
Extra credit: 2c) Have an automated, non-interactive boot option to run
CHIPSEC, save a dump of the system firmware (chipsec_util spi dump
rom.bim), and generate a hash of that image. For both UEFI Shell and
Linux versions of CHIPSEC. :-)
3) Have an option to run FWTS interactively, like FWTS-live does.
In addition to CHIPSEC, FWTS, Canonical's FirmWare TestSuite is also a
good set of pre-boot tools to run, especially for ACPI. Running FWTS in
a boot option, like FWTS-live does would be ideal. BTW, please pdate
FWTS's Secure Boot test to support Debian and Rescatux keys, it only
currently supports Ubuntu key. In addition to Intel, FWTS also supports
ARM and OpenPOWER, so you have some more images to create. :-)
4) Other LUV tests?
LUV-live may have a few other tests you might want to think about
running as boot options in Rescatux. BITS, for example.
5) Use Intel TXT on your system, so we can trust anything you say. If
attacker has taken over a system, all test results (eg, CHIPSEC security
test results) can be faked.
Hope this helps.
personal blog: https://firmwaresecurity.com/