proxmox-mirrors/fwupd
1
0
Fork 0
mirror of https://git.proxmox.com/git/fwupd synced 2025-05-24 15:05:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

trivial: Add some Impact sections to HSI attributes

Browse Source
This commit is contained in:
Richard Hughes 2021-11-05 14:52:31 +00:00
parent ed419416d5
commit 54f1557a81
1 changed files with 120 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

166
docs/hsi.md
View File

@ -144,7 +144,9 @@ UEFI Secure boot is a verification mechanism for ensuring that code launched by
Secure Boot requires that each binary loaded at boot is validated against trusted certificates.
Possible results:
**Impact:** When Secure Boot is not enabled any EFI binary can be run at startup, which gives the attacker full access to your hardware.
**Possible results:**
- `not-found`: support has not been detected
- `not-enabled`: detected, but has been turned off
@ -152,7 +154,11 @@ Possible results:
To meet HSI-1 on UEFI systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**Resolution:**
Turn off CSM boot and enable Secure Boot in the BIOS setup.
**References:**
- [Ubuntu SecureBoot Wiki Page](https://wiki.ubuntu.com/UEFI/SecureBoot)
@ -163,14 +169,17 @@ References:
UEFI defines a platform key for the system.
This should not be a test key, e.g. `DO NOT TRUST - AMI Test PK`
Possible results:
**Impact:** It is possible to sign an EFI binary with the test platform key, which invalidates the Secure Boot trust chain.
It effectively gives the local attacker full access to your hardware.
**Possible results:**
- `valid`: valid key
- `not-valid`: an invalid key has been enrolled
To meet HSI-1 on UEFI systems that run this test, the result must be `valid`. *[v1.5.0]*
References:
**References:**
- [Ubuntu SecureBoot Wiki Page](https://wiki.ubuntu.com/UEFI/SecureBoot/Testing)
@ -181,7 +190,10 @@ References:
Intel hardware provides this mechanism to protect the SPI ROM chip located on the motherboard from being overwritten by the operating
system. The `BIOSWE` bit must be unset otherwise userspace can write to the SPI chip.
Possible results:
**Impact:** The system firmware can be written from userspace.
This gives any attacker with root access a method to write persistent executable code to the firmware, which survives even a full disk wipe and OS reinstall.
**Possible results:**
- `not-found`: the SPI device was not found
- `not-enabled`: write enable is disabled
@ -189,7 +201,7 @@ Possible results:
To meet HSI-1 on systems that run this test, the result must be `not-enabled`. *[v1.5.0]*
References:
**References:**
- [Intel C200 Datasheet](https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf)
@ -200,14 +212,17 @@ References:
If the lock bit is set then System Management Interrupts (SMIs) are raised when setting BIOS Write Enable.
The `BLE` bit must be enabled in the PCH otherwise `BIOSWE` can easily be unset.
Possible results:
**Impact:** The system firmware can be written from userspace.
This gives any attacker with root access a method to write persistent executable code to the firmware, which survives even a full disk wipe and OS reinstall.
**Possible results:**
- `enabled`: the register is locked
- `not-enabled`: the register is not locked
To meet HSI-1 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**References:**
- [Intel C200 Datasheet](https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf)
@ -218,14 +233,17 @@ References:
This bit set defines when the BIOS region can be written by the host.
The `SMM_BWP` bit must be set to make the BIOS region non-writable unless all processors are in system management mode.
Possible results:
**Impact:** The system firmware can be written from userspace by exploiting a race condition in checking `BLE`.
This gives any attacker with root access a method to write persistent executable code to the firmware, which survives even a full disk wipe and OS reinstall.
**Possible results:**
- `locked`: the region is locked
- `not-locked`: the region is not locked
To meet HSI-1 on systems that run this test, the result must be `locked`. *[v1.5.0]*
References:
**References:**
- [Intel C200 Datasheet](https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf)
@ -236,7 +254,10 @@ References:
The SPI descriptor must always be read only from all other regions.
Additionally on Intel architectures the FLOCKDN register must be set to prevent configuration registers in the SPI BAR from being changed.
Possible results:
**Impact:** The system firmware can be written from userspace by changing the protected region.
This gives any attacker with root access a method to write persistent executable code to the firmware, which survives even a full disk wipe and OS reinstall.
**Possible results:**
- `not-valid`: any region can write to the flash descriptor
- `locked`: the SPI BAR is locked and read only from all regions
@ -250,7 +271,10 @@ To meet HSI-1 on systems that run this test, the result must be `locked`. *[v1.6
A TPM securely stores platform specific secrets that can only be divulged to trusted consumers in a secure environment.
Possible results:
**Impact:** The PCR registers will not be available for use by the bootloader and kernel.
This means userspace cannot either encrypt disks to the specific machine, and also can't know if the system firmware was externally modified.
**Possible results:**
- `found`: device found in v2 mode
- `not-found`: no device found
@ -258,7 +282,7 @@ Possible results:
To meet HSI-1 on systems that run this test, the result must be `found`. *[v1.5.0]*
References:
**References:**
- [TPM Wikipedia Page](https://en.wikipedia.org/wiki/Trusted_Platform_Module)
@ -269,14 +293,17 @@ References:
There have been some unfortunate cases of the ME being distributed in manufacturing mode.
In manufacturing mode many features from the ME can be interacted with that decrease the platform's security.
Possible results:
**Impact:** If the ME is in manufacturing mode then any user with root access can provision the ME engine with new keys.
This gives them full access to the system even when the system is powered off.
**Possible results:**
- `locked`: device has had manufacturing mode disabled
- `not-locked`: device is in manufacturing mode
To meet HSI-1 on systems that run this test, the result must be `locked`. *[v1.5.0]*
References:
**References:**
- [ME Manufacturing Mode: obscured dangers](https://malware.news/t/intel-me-manufacturing-mode-obscured-dangers-and-their-relationship-to-apple-macbook-vulnerability-cve-2018-4251/23214)
- [Intel security advisory SA-00086](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html)
@ -288,14 +315,17 @@ References:
The Flash Descriptor Security Override Strap is not accessible to end users on consumer boards and Intel stresses that this is for debugging
only.
Possible results:
**Impact:** The system firmware can be written from userspace by changing the protected region.
This gives any attacker with root access a method to write persistent executable code to the firmware, which survives even a full disk wipe and OS reinstall.
**Possible results:**
- `locked`: device in in normal runtime mode
- `not-locked`: device is in debugging mode
To meet HSI-1 on systems that run this test, the result must be `locked`. *[v1.5.0]*
References:
**References:**
- [Chromium documentation for Intel ME](https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/Documentation/mysteries_intel.txt)
@ -307,14 +337,16 @@ Converged Security and Manageability Engine is a standalone management module th
The CSME lives in the PCH and can only be updated by the OEM vendor.
The version of the CSME module can be checked to detect the most common and serious vulnerabilities: CVE-2017-5705, CVE-2017-5708, CVE-2017-5711, CVE-2017-5712, CVE-2017-5711, CVE-2017-5712, CVE-2017-5706, CVE-2017-5709, CVE-2017-5707 or CVE-2017-5710.
Possible results:
**Impact:** Using any one of the critical vulnerabilities, a remote attacker can take full control of the system and all connected devices, even when the system is powered off.
**Possible results:**
- `valid`: affected by one of the below CVEs
- `not-valid`: is not affected by the most critical CVEs
To meet HSI-1 on systems that run this test, the result must be `valid`. *[v1.5.0]*
References:
**References:**
- [Intel CSME Security Review Cumulative Update](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html)
@ -324,14 +356,17 @@ References:
Newer Intel CPUs support debugging over USB3 via a proprietary Direct Connection Interface (DCI) with the use of off-the-shelf hardware.
Possible results:
**Impact:** Using DCI an attacker with physical access to the computer has full access to all registers and memory in the system, and is able to make changes.
This makes privilege escalation from user to root possible, and also modifying SMM makes it possible to write to system firmware for a persistent backdoor.
**Possible results:**
- `enabled`: debugging is currently enabled
- `not-enabled`: debugging is not currently enabled
To meet HSI-1 on systems that run this test, the result must be `not-enabled`. *[v1.5.0]*
References:
**References:**
- [Intel Direct Connect Interface](https://www.intel.co.uk/content/www/uk/en/support/articles/000029393/processors.html)
- [Chipsec 4xxlp register definitions](https://github.com/chipsec/chipsec/blob/master/chipsec/cfg/8086/pch_4xxlp.xml#L270)
@ -343,14 +378,17 @@ References:
Newer Intel CPUs support debugging over USB3 via a proprietary Direct Connection Interface (DCI) with the use of off-the-shelf hardware.
Possible results:
**Impact:** A local attacker with root access would be able to enable DCI. This would allow them full access to all registers and memory in the system, and is able to make changes.
This allows using SMM to write to system firmware for a persistent backdoor.
**Possible results:**
- `locked`: CPU debugging has been disabled
- `not-locked`: is is still possible to enable CPU debugging
To meet HSI-2 on systems that run this test, the result must be `locked`. *[v1.5.0]*
References:
**References:**
- [Intel Direct Connect Interface](https://www.intel.co.uk/content/www/uk/en/support/articles/000029393/processors.html)
@ -362,7 +400,9 @@ The TPM event log records which events are registered for the PCR0 hash.
When reconstructed the event log values should always match the TPM PCR0.
If extra events are included in the event log, or some are missing, the reconstitution will fail.
Possible results:
**Impact:** This is not a vulnerability per-se, but it shows that the system firmware checksum cannot be verified as the PCR result has been calculated incorrectly.
**Possible results:**
- `valid`: all correct
- `not-valid`: could not reconstitute the hash value
@ -370,7 +410,7 @@ Possible results:
To meet HSI-2 on systems that run this test, the result must be `valid`. *[v1.5.0]*
References:
**References:**
- [Linux Kernel TPM Documentation](https://www.kernel.org/doc/html/latest/security/tpm/tpm_event_log.html)
@ -382,7 +422,11 @@ The IOMMU on modern systems is used to mitigate against DMA attacks.
All I/O for devices capable of DMA is mapped into a private virtual memory region.
The ACPI DMAR table is used to set up pre-boot DMA protection which eliminates some firmware attacks.
Possible results:
**Impact:** Without a DMAR table the IOMMU is disabled at boot.
An attacker could connect a malicious peripheral using ThunderBolt and reboot the machine, which would allow the attacker to modify the system memory.
This would allow subverting the Secure Boot protection, and also invalidate any system attestation.
**Possible results:**
- `enabled`: detected correctly
- `not-valid`: could not determine state
@ -390,7 +434,7 @@ Possible results:
To meet HSI-2 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**References:**
- [IOMMU Wikipedia Page](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit)
@ -402,14 +446,17 @@ References:
BootGuard is a processor feature that prevents the machine from running firmware images not released by the system manufacturer.
It forms a root-of-trust by fusing in cryptographic keys into the processor itself that are used to verify the Authenticated Code Modules found in the SPI flash.
Possible results:
**Impact:** When BootGuard is not set up correctly then the chain-of-trust between the CPU and the bootloader can not be verified.
This would allow subverting the Secure Boot protection which gives the attacker full access to your hardware.
**Possible results:**
- `enabled`: detected and enabled
- `not-enabled`: not detected, or detected but not enabled
To meet HSI-2 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**References:**
- [Coreboot documentation](https://github.com/coreboot/coreboot/blob/master/src/soc/intel/jasperlake/include/soc/me.h)
@ -420,7 +467,10 @@ References:
BootGuard is a processor feature that prevents the machine from running firmware images not released by the system manufacturer.
It forms a root-of-trust by fusing in cryptographic keys into the processor itself that are used to verify the Authenticated Code Modules found in the SPI flash.
Possible results:
**Impact:** When BootGuard is not set up correctly then the chain-of-trust between the CPU and the bootloader can not be verified.
This would allow subverting the Secure Boot protection which gives the attacker full access to your hardware.
**Possible results:**
- `success`: verified boot chain
- `not-valid`: boot is not verified
@ -434,7 +484,10 @@ To meet HSI-2 on systems that run this test, the result must be `success`. *[v1.
BootGuard is a processor feature that prevents the machine from running firmware images not released by the system manufacturer.
It forms a root-of-trust by fusing in cryptographic keys into the processor itself that are used to verify the Authenticated Code Modules found in the SPI flash.
Possible results:
**Impact:** When BootGuard is not set up correctly then the chain-of-trust between the CPU and the bootloader can not be verified.
This would allow subverting the Secure Boot protection which gives the attacker full access to your hardware.
**Possible results:**
- `valid`: ACM protected
- `not-valid`: boot is not verified
@ -448,7 +501,9 @@ To meet HSI-2 on systems that run this test, the result must be `valid`. *[v1.5.
BootGuard is a processor feature that prevents the machine from running firmware images not released by the system manufacturer.
It forms a root-of-trust by fusing in cryptographic keys into the processor itself that are used to verify the Authenticated Code Modules found in the SPI flash.
Possible results:
**Impact:** The attacker can invalidate the chain of trust (subverting Secure Boot), and the user would get just a console warning and then continue to boot.
**Possible results:**
- `valid`: error enforce policy is set to shutdown
- `not-valid`: policy is invalid
@ -462,7 +517,10 @@ To meet HSI-2 on systems that run this test, the result must be `valid`. *[v1.5.
BootGuard is a processor feature that prevents the machine from running firmware images not released by the system manufacturer.
It forms a root-of-trust by fusing in cryptographic keys into the processor itself that are used to verify the Authenticated Code Modules found in the SPI flash.
Possible results:
**Impact:** When BootGuard is not set up correctly then the chain-of-trust between the CPU and the bootloader can not be verified.
This would allow subverting the Secure Boot protection which gives the attacker full access to your hardware.
**Possible results:**
- `valid`: SOC is locked
- `not-valid`: SOC is not locked
@ -477,7 +535,9 @@ Suspend to Ram (S3) keeps the raw contents of the DRAM refreshed when the system
This means that the memory modules can be physically removed and the contents recovered, or a cold boot attack can be performed with a USB device.
The firmware should be configured to prefer using suspend to idle instead of suspend to ram or to not offer suspend to RAM.
Possible results:
**Impact:** An attacker with physical access to a system can obtain the un-encrypted contents of the RAM by suspending the machine, removing the DIMM and inserting it into another machine with modified DRAM controller before the memory contents decay.
**Possible results:**
- `enabled`: sleep enabled
- `not-enabled`: suspend-to-ram being used
@ -485,7 +545,7 @@ Possible results:
To meet HSI-3 on systems that run this test, the result must be `not-enabled`. *[v1.5.0]*
References:
**References:**
- [Cold Boot Attack Wikipedia Page](https://en.wikipedia.org/wiki/Cold_boot_attack)
@ -495,14 +555,16 @@ References:
Control enforcement technology is available on new Intel platforms and prevents exploits from hijacking the control-flow transfer instructions for both forward-edge (indirect call/jmp) and back-edge transfer (ret).
Possible results:
**Impact:** A local or physical attacker with an existing unrelated vulnerability can use a reliable and well-known method to run arbitrary code.
**Possible results:**
- `enabled`: feature enabled by the platform
- `not-supported`: not supported
To meet HSI-3 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**References:**
- [Intel CET Technology Preview](https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf)
@ -512,14 +574,16 @@ References:
Control enforcement technology is available on new Intel platforms and prevents exploits from hijacking the control-flow transfer instructions for both forward-edge (indirect call/jmp) and back-edge transfer (ret).
Possible results:
**Impact:** A local or physical attacker with an existing unrelated vulnerability can use a ROP gadget to run arbitrary code.
**Possible results:**
- `supported`: being used
- `not-supported`: not being used by the host
To meet HSI-3 on systems that run this test, the result must be `supported`. *[v1.5.0]*
References:
**References:**
- [Intel CET Technology Preview](https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf)
@ -530,14 +594,16 @@ References:
TME (Intel) or TSME (AMD) is used by the firmware on supported SOCs to encrypt all data on external memory buses.
It mitigates against an attacker being able to capture memory data while the system is running or to capture memory by removing a DRAM chip.
Possible results:
**Impact:** A local attacker can either extract unencrypted content by attaching debug probes on the DIM modules, or by removing them and inserting them into a computer with a modified DRAM controller.
**Possible results:**
- `enabled`: detected and enabled
- `not-supported`: not available
To meet HSI-4 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**References:**
- [Intel TME Press Release](https://software.intel.com/content/www/us/en/develop/blogs/intel-releases-new-technology-specification-for-memory-encryption.html)
- [WikiChip SME Overview](https://en.wikichip.org/wiki/x86/sme)
@ -549,14 +615,16 @@ References:
Without Supervisor Mode Access Prevention, the supervisor code usually has full read and write access to user-space memory mappings.
This can make exploits easier to write, as it allows the kernel to access user-space memory when it did not intend to.
Possible results:
**Impact:** A local or remote attacker can use a simple exploit to modify the contents of kernel memory which can lead to privilege escalation.
**Possible results:**
- `enabled`: features are detected and enabled
- `not-supported`: not enabled
To meet HSI-4 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**References:**
- [SMAP Wikipedia Page](https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention)
@ -568,14 +636,18 @@ The IOMMU on modern systems is used to mitigate against DMA attacks.
All I/O for devices capable of DMA is mapped into a private virtual memory region.
Common implementations are Intel VT-d and AMD-Vi.
Possible results:
**Impact:** An attacker with inexpensive PCIe development hardware can write to system RAM from the ThunderBolt or Firewire ports which can lead to privilege escalation.
**Possible results:**
- `enabled`: hardware detected and enabled
- `not-found`: hardware was not detected
To meet HSI-2 on systems that run this test, the result must be `enabled`. *[v1.5.0]*
References:
**Resolution:** If available, turn on IOMMU in the system BIOS.
**References:**
- [IOMMU Wikipedia Page](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit)
@ -585,7 +657,9 @@ References:
The platform should be set up with Suspend-to-Idle as the default S3 sleep state.
Possible results:
**Impact:** A local attacker could overwrite the S3 resume script to modify system RAM which can lead to privilege escalation.
**Possible results:**
- `enabled`: deep sleep enabled
- `not-enabled`: suspend-to-idle being used