SCAP reporting support for CHIPSEC
by Blibbet
Hijacking one of John's comments on Debian packaging:
> [...] we should probably print some shorter and more friendly output.
Perhaps
> something more like "Protection Found"/"Possible
Vulnerability"/"Manual Assessment
> Needed"?
>
> BIOS Write Protection: Possible Vulnerability
> SMI Suppression: Possible Vulnerability
> Compatibility SMRAM Lock: Protection Found
> SMM Cache Poisoning: Protection Found
> UEFI Variables: Manual Assessment Needed
>
> How would others like to view/use this sort of information?
I'd like to use this sort of information as machine-readable SCAP XML,
so CHIPSEC output can be fed into current enterprise CM/SIEM solutions.
Then, the question of what format is more of needing SCAP OVAL
definitions for Intel HW/FW assets, and then SCAP ARF-based report
plugin for CHIPSEC.
SCAP isn't needed for security researcher usage of CHIPSEC. BUT IMO,
SCAP would be very useful for system administrator's use of CHIPSEC, but
I'm not sure anyone is asking yet.
Currently, SCAP is not too useful for searching for firmware. Today, if
you want to look for BIOS or UEFI (or EFI 1.x) vulnerabilities in NVD,
it's only via full-text search, and hoping reporting of error happens to
include UEFI. Thus the need for SCAP OVAL definitions. (Then UEFI Forum
could not only report vulnerabilities as PDFs -- hosted on SourceForge's
reliable CDN :-) -- but also as CVEs in the NVD (which has also gone
down like SF, but XML content is mirrored by multiple orgs. CHIPSEC --
or Copernicus, if MITRE is maintaining it -- would be needed to fix
SCAP, as there aren't any other vulnerability reporting tools to
generate the needed ARF reports. Maybe -- I've not studied it closely
yet -- the BIOS profile by DMTF's SMASH-and-DASH team might be helpful
for SCAP OVAL starting point?
I presume Intel could make good marketing use of this improved
enterprise security feature. If/when Linaro ports CHIPSEC to AArch64, I
presume some of the anticipated green Linux server market will also like
to have this feature. :-)
Thanks,
Lee
RSS: http://firmwaresecurity.com/feed
5 years, 5 months
Debian packaging and D-I integration
by Blibbet
Hi,
I'm interested in CHIPSEC packages for Debian.
However, this is my FIRST attempt at doing Debian packaging, and CHIPSEC
a complex target, with Python, C, Intel x86 and x64 assembly, dynamic
kernel driver with security issues. I could use some help from others
that're more experienced with Debian packaging. If you want to help with
packaging, or know any answers to below qustions, please speak up.
For packaging, how about:
chipsec-uefi - UEFI binaries
chipsec-dkms - Linux kernel module src, compiled via dkms
chipsec-utils - Linux userland tools
Perhaps chipsec-uefi needs to be split up to one package per arch,
chipsec-uefi-x86, chipsec-uefi-x64, and chipsec-aarch64? Linaro is
investigating porting CHIPSEC to AArch64. If that happens, we'd need a
chipsec-uefi-aarch64 package. We could share the source packages, if
Linaro and Intel share same codebase, else may need separate source
packages for Intel and ARM flavors.
Right now, CHIPSEC driver gets loaded dynamically. Leaving the driver
loaded is a BIG security risk, see CHIPSEC's warning.txt file. AFAICT,
the big problem for CHIPSEC packaging is to keep the CHIPSEC Linux
helper driver unloaded most of the time, and only loade when CHIPSEC is
run, and unloaded afterwards. I don't understand how to address
packaging of drivers that do post-boot Linux module loading. From what I
gather, this ability would likely be disabled on more secure systems
(where CHIPSEC might want to be used).
I don't understand the Debian Python packaging specifics, and how this
impacts the package. There are separate guidelines for Python apps and
Python libraries, and CHIPSEC is both (it is multiple apps, as well as a
library). I'd like to find some example of an existing package with
Python code that loads/uses/unloads DKMS-based drivers.
I presume initially CHIPSEC packaging needs to not be put on a
mainstream Debian repository, to avoid driver security problems, and
only be kept on a private place, where only people who know the CHIPSEC
risks can install the package.
Most packaging happens in batch mode, non-interactively. But perhaps the
CHIPSEC driver package should display the contents of CHIPSEC's
warning.txt and let the use agree to this security risk, before
installing? If so, I need to find out how to do that in a Debian package.
Since CHIPSEC will only work on Intel x86/x64 systems, and not AMD-based
AMD64 systems, installation has to check CPU and only install on proper
systems. I'm unclear how to do this check in a Debian package.
LUV currently is the only Linux distro that ships with CHIPSEC. LUV is
Yocto-based, and as I understand it Yocto supports Debian packaging, but
I'm unclear if it can consume them or only produce them. Could LUV be
able to consume a Debian CHIPSEC package?
I'm also interested in getting CHIPSEC integrated to the installation
process. I really like the firmware diagnostic abilities of Linux UEFI
Validation (LUVos, and LUV-live), currently the only Linux distro that
ships with CHIPSEC (no packaging, Matt manually patches CHISPEC github
drops). I like how ALT Linux Rescue's ISO ships with an EFI-based boot
manager (rEFInd), and ships UEFI Shell on ISO's ESP, so user can boot
into UEFI Shell or continue running Linux installer. I'd like to see
some of those abilities in mainstream Linux installers. I think Debian
Installer (D-I) should offer the ability to have an ESP on it's ISO that
includes UEFi Shell, UEFI Python, and CHIPSEC. Then, D-I could let user
boot into UEFI to do pre-install diagnostics. It could also offer
additional Linux-based pre-install diagnostics (CHIPSEC, BITS, FWTS,
etc.) for additional pre-install diagnostics.
In addition to offering pre-OS and OS-present CHIPSEC as pre-install
tool, I think it'd also be useful to install CHIPSEC onto system, for
post-install-time use of CHIPSEC on the newly-installed Linux system.
Again, the issue of keeping the kernel driver unloaded and otherwise not
available to attackers is key.
One nice thing about integrating CHIPSEC with installer is that
install-time scopes use of CHIPSEC, and thus the CHIPSEC kernel driver
security is constrained to only when installer is run. (That's why I'm
complicating this packaging discussion with installer changes...)
I was talking to Paul Wise of Debian about install-time and
post-install-time use of CHIPSEC use, and he suggested some possible
workflows Debian could enable:
On a server:
apt-get install chipsec-efi-amd64
CHIPSEC auto-installed into UEFI boot menu
Reboot server
Select UEFI checks at boot menu
Checks complete successfully
Boot into OS
On a dev/sysadmin laptop:
apt-get install chipsec-efi-amd64-bin chipsec-tools
mkfs.vfat /dev/sdb1
mount /dev/sdb1 tmp
cp /usr/lib/chipsec/x86_64-efi/chipsec.img tmp
Eject USB stick
Boot USB on server
Select checks at boot menu
Checks complete successfully
Boot into OS
Download Debian hardware/firmware checks live CD/USB
Select UEFI checks at boot menu
Checks complete successfully
Boot into OS
Run OS-level checks
Download Debian installer
Boot in expert mode
Asks to check firmware security
Checks complete successfully
Continue installation
What other special CHISPEC packaging issues have I forgotten to consider?
Any other suggestions as to how to help improve Installer's Pre-OS/OS
use of CHIPSEC?
Thanks,
Lee Fisher
RSS: http://firmwaresecurity.com/feed
5 years, 5 months
Native Mac Support for Chipsec?
by Darren Bilby
Just wondering if there is any intention to officially support OSX with
Chipsec. Getting it running from a bootable USB drive on a Mac is pretty
simple (e.g. https://sevenbits.github.io/Mac-Linux-USB-Loader + git clone)
, but would be great to be able to have the option to run it natively.
I'm guessing the driver is the key issue? There is some basic raw
read/write support implemented in the Pmem memory forensics driver which
might be a reasonable start, and I have support from the Rekall team for
adding the right primitives there if it was considered a reasonable path:
https://github.com/google/rekall/tree/master/tools/osx/MacPmem
Is the key factor in support just time/contributions? or are there factors
to consider before considering this?
Thanks, Darren.
5 years, 5 months
