Re: Rescatux 0.41b1 released with UEFI rescue options
On 04/30/2017 07:21 AM, adrian15 wrote:
> El 24/04/17 a las 20:02, Lee Fisher escribió:
>> 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!
>>
>> Hi,
>>
>> 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
>> Shell.
> Is there an standard UEFI shell somewhere packaged for Debian that I can
> use?
Not that I know of. You'll have to build it from EDK2 source, or trust
the pre-built binaries from the EDK2's ShellBinPkg.
> I guess uefi-chainloading from Grub2 will be trivial.
>>
>> 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.
>> https://lists.01.org/pipermail/chipsec/2015-July/000004.html
>>
>> 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
>> batch log.)
>>
>> 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. :-)
> Well, first time that I learn about CHIPSEC.
> Rescatux's audience is newbies but I'm open to add packages such as
> gparted, gpart or testdisk for more experienced people.
>
> First of all Rescatux does not support 'Secure Boot' yet because I was
> expecting on reusing or relying on Debian's 'Secure Boot' but it seems
> it won't be for initial Stretch release (maybe an update release will
> have it).
>
> Were you assuming that Rescatux was going to support 'Secure Boot' or not?
>
CHIPSEC does not imply Secure Boot. CHIPSEC is a vulnerability scanner
that looks for OEM implementation issues in BIOS, UEFI (with or without
Secure Boot). For x86/64 systems, it is the only tool available to test
if a box was designed insecurely or not. Most of CHIPSEC's features are
not related to Secure Boot.
> So, I'm not sure how useful it would be to run CHIPSEC if Rescatux boot
> itself is not self-verified by the UEFI.
Running CHIPSEC on a system is a useful feature for a rescue
distribution, regardless of Secure Boot support.
> If you know how to write something so that this is easily integrated
> into Rescatux (e.g. a CHIPSEC enabled kernel package) then I'm open for
> it. I can add it.
>
> What I'm not going to do is to learn how to build CHIPSEC, how it's
> supposed to work (I would have to check if it actually works as expected
> or not), and more things.
Once installed, "python -m chipsec_main" will run most of the security
tests. "python -m chipsec_util spi dump rom.bin" will dump the rom of a
system. Besides these, you might want to run the blacklist and whitelist
tools.
> But if you know how to install these suite manually and what you are
> missing is a live cd that includes it then I can help you. I can be that
> live cd.
>
> I won't also work on colorized output.
>
> I can help on adding Rescapp options so that you can run the different
> CHIPSEC tests individually from Rescapp if you want to.
>
> As Rescapp already puts the commands output into a log file you could
> then share that log into a forum or a pastebin very easily with two clicks.
>
>>
>> 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,
> Is this program available from a ppa?
Yes.
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
> I could easily add it then.
> Yeah, well, 'Secure Boot' I already commented before.
Like CHIPSEC, FWTS is not tied to Secure Boot. FWTS finds many defects,
a useful feature of a Linux rescue/diagnostic distro. It also has some
Secure Boot features, not required to use.
FWTS and CHIPSEC will run on BIOS systems, no UEFI needed.
>> FWTS also supports
>> ARM and OpenPOWER, so you have some more images to create. :-)
> I already have too much struggle with amd64 and x86 where source code is
> not well packed from the live-build project.
>
>>
>> 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.
> If it's just a matter of adding a package or a simple script that you
> can guide me I'm open for it but I won't work actively on it.
LUV is Yocto-based, not Debian-based. Yocto uses Bitbake for recipes.
Yocto will read DEB packages, but I am not sure that any of the
UEFI-centric features are packaged up that way.
https://github.com/01org/luv-yocto
>> 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.
> Once again you can instruct me on how to do that and depending how
> difficult it is (and also how much bigger Rescatux becomes. I don't want
> it to be more than 700 MB if possible) I might add it or not.
I am unclear how to use TXT at the OS-level, only at UEFI level. I'd
defer to some Debian/Intel kernel experts for that.
https://en.wikipedia.org/wiki/Trusted_Execution_Technology
>> Hope this helps.
>>
>> Thanks,
>> Lee Fisher
>> https://preossec.com/
>> personal blog: https://firmwaresecurity.com/
>
>> 6) Check UEFI DBX revocation file for bad Secure Boot certs
>
> Same as before.
Same as before, you don't need to have Rescatux support Secure Boot in
order to check if the UEFI's keys are bad/revoked. Having bad keys is
like having a browser with Diginotar root CA installed, and not having
the ability to update your keys. I'd hope that a rescue distro would
care to help the user with a serious problem like this.
> BTW, Rescatux includes SELinux for the sole purpose of being able to fix
> SELinux systems such as RedHat, Fedora and so on. Unfortunately due to
> jessie bugs ssh-server package is not installable when booted in that mode.
Redhat has dbxtool, which you can use to help with DBX file checks. I
don't think Debian has any downstream support you can use. :-(
> Thank you very much for your feedback. I learnt some stuff I wasn't
> aware of.
>
> adrian15
Sorry just contributing ideas -- not implementations -- to Rescatux. If
I had time to implement all these features, I would have already
submitted a patch to D-I with an 'Advanced UEFI Diagnostics' menu. :-)
Thanks,
Lee
Reply to: