Background

The majority of infosec community are trying to ignore the risks below the OS in past decades but it’s impossible to bury all of them at low cost today. In other words, the time has changed. U.S government issued Executive Order (EO 14028) on Improving the Nation’s Cybersecurity to address multiple important issues. SBOM (Software Bill of Materials) is one of them and it’s trying to improve the software supply chain security by requiring the vendor provides more information about the components of their product/solution. A few weeks after, the Cybersecurity and Infrastructure Security Agency (CISA) announced a new campaign called VBOS - “vulnerabilities below the operating system” at RSA conference, to promote SBOM extending to firmware level. NIST released Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028 to guides the vendor and public sectors how to deal with critical software in July 2021.

Keep this in mind: Firmware is a special software, critical ones.

Are we always missed something?

The concept of complexity is too complex to explain. You need to deal with “complexity” everyday if you work in the infosec industry. Some threats and risk are comparatively easy to understand but usually time-consuming. To figure out the way to mitigate most known risks may be easy, while others aren’t not. Intel ME is definitely not belong to any type of low-hanging fruits. Intel introduced ME (Management Engine) into the chipset back in 2008. It has higher priviledges than OS, which means any detection techniques at OS level doesn’t work on the attack from ME. Alexander Tereshkin and Rafal Wojtczuk demonstrated the possibility to implant the Ring -3 Rootkits(Notes: In this context, application: Ring 3; Linux kernel: Ring 0; Virtualization: Ring -1; BIOS/UEFI/SMM: Ring -2; Intel ME: Ring -3) in 2009.

Another interesting research is DAGGER released in 2014. Unfortunately, most people didn’t even know this thing’s existence until Google try to kill it in 2017.

The history of ME

Intel renamed ME to CSME (Converged Security and Management Engine) since Kabylake. Maybe because Intel binded TXT (Trusted Execution Technolog) with BootGuard as one feature called CBnT in the same generation of chipset with KabyLake. Intel CSME/SPS is one of independent IPs inside PCH running the independent OS just like a tiny computer in all x86 machines (server, desktop, laptop and embedded SoC). SPS (Server Platform Service) is the implementation of CSME for x86 server.

	ME	ME	ME	ME	ME
Version	1.x – 5.x	6.x – 10.x	11.x	12.x	15.x
Core	ARCTangent-A4	ARCompact	Quark	Quark	Quark(?)
Instruction set	ARC (32-bit)	ARCompact (32/16)	x86 (32-bit)	x86 (32-bit)	x86 (32-bit)
Mitigation	N/A	N/A	NX	SMEP	CET/CFI
OS	??	ThreadX	MINIX	MINIX	MINIX
SPS	SPSv1.x	SPSv2.x – v3.x	SPSv4.x	SPSv5.x	SPSv6.x

Threat models & attack surfaces

The attack chain is long and we don’t know if it ever exist yet. According to the Murphy’s law: If the attacker could do it, they would do it.

• Ring 3 exploited (webshell or other RCE in apps) successfully and the entry of the underground “RING 0” is doomed to compromised.
• Not much concerns of “RING -1” due to practical malware samplings.
• Writing crafted payload to the firmware “RING -2”, e.g: coreboot/UEFI via physical access or bypassing chipset mitigations.
• Triggering the 0day or known vunerablity (e.g: SA-00086) in early stage of CSME, e.g: RBE or the kernel which can’t be neutralized in post-Skylake( >= CSMEv11) to gaining full control of CSME. The attacker is likely to enable the VISA based on the foothold of the control of CSME. Otherwise, the attacker can just replace the vendor firmware with their own which can perform RS1 DMA operations before IOMMU being enabled.

If that’s the case, it’s very difficult to let forensics team do their job. It’s another reason you should take firmware security serious.

WARNING: Any experiments on CSME could possibly burn the PCH. Be cautions if you’re determined to tweak your PoC;-)

ME manufacturing mode

ME Manufacturing mode is one of CSME operational mode which designed for maintainence purpose for OEM vendor. There’s one thing at least every CISO and security engineer should be aware of: Some vendors ship the server and a jumper as a switch for ME manufacturing mode on its mainboard. It’s a huge security risk. Even if you provisioned the multi trust anchors (e.g: RoT (Root of Trust), etc), it could be still problematic to your production. Our product Vault 111 Hardened server faced this issue during the development. Then we tried to contact with the vendor:

We were expecting an option to work out this issue at firmware level but not design the whole PCB:

Unfortunately, they have no idea what we were talking about:

We don’t blame them because hardware vendor take care of typical issue for the general use case without much concern about security. But the role of security professional might have other opionion about it.

Should I disable CSME?

It’s complicated. The 1st question would be like do you trust Intel or how odds Intel would implant the backdoor other than OEMs? Some users value the digital freedom over other factors. They are willing to disable CSME at any cost though. Let’s says most of users are willing to have leap of faith in Intel. So we don’t count the backdoor issue here. As a CISO or security engineer, you’re going to face the vulnerablity issue as we mentioned a bit in threat models section. Believe it or not, CSME has tons of vulnerablities being disclosed each year. Two factors must be taken into account:

• CSME self-defense ability
• How many CSME security features do you want badly?

From HardenedVault’s perspective, the 1st factor is easy to measure:

Version	Mitigation	Vulnerablity risk
<= CSMEv11/SPSv3	NX	High
<= CSMEv14/SPSv5	NX/SMEP	Medium
>= CSMEv15/SPSv6	NX/SMEP/CET	Low

NX is a decades old mitigation originally developed by PaX team in 2000. It was design to prevent code execution on the stack. SMEP is doing the similar thing but for the linux kernel. It was originally developed by PaX team as KERNEXEC in 2004. CET is ensure the code flow integrity introduced by Intel in TigerLake but CSMEv15/SPSv6 processor have this feature as well.

The 2nd factor is bit of tricky because the biggest advantage of CSME is that it provides important security features, e.g: CBnT, SGX, etc. CBnT can work as RoT which other chains of trust are based on. If you disabled CSME, you’re likely to lost the chance to use those features. Well, you can build other trust anchors as well. Make sure that you have proper physical protection for the server if you don’t have the root of trust. Maybe we can figure out a way to keep those security features while disable CSME at runtime after CSME hardware done its initialization.

Can I disable CSME?

Yes and no. There are a couple of options you have for CSME:

Type	Results	Date
Code removal	If you remove all CSME modules on post-Core 2, your computer will reboot every 30 mins	~2010
Neutralized	By minimizing the code modules	2016
Disable	altmedisable/HAP is set in IFD ME will temporily disabled after ME hardware initializaton	2017
Disable	Temporily disabled a runtime via HECI/HMRFPO	2018

Please noted that none of above methods can be utilized to disable SPSv5. SPSv5 is a beast caused all open source parsers thwarted due to the VFS was added. We provide a workaround option to cripple SPS/CSME by default to the customer who want to disable CSME. The way our workaround option is able to disable CSME and ME manufacturing mode, while the CSME security features may not work any longer:

Does AMD have the similar issue?

Yes, the equivalent of CSME is PSP (Platform Security Processor) on AMD chipset.

I use enclave solution like SGX/SEV, why do I care CSME?

According to the public disclosures, we can have some important information during our assessment:

• The processor of CSMEv12 began to ship mitigations like SMEP by default. But side channel issues (Meltdown/Spectre variants) still are big issues as well as modern x86. L1TF is an example.
• Some public disclosures reveal the possiblity that MEE can be accessed by ME.
• The implmentation of AMD SEV is more rely on PSP firmware rather than other components, e.g: microcode plays the big role in SGX while CSME code modules only provide limited support. The threat model of SEV is different to SGX.

Do we have open source alternatives?

No, there’s no open source alternative. Intel CSME is a blackbox can’t be audited properly. Hackers and security professionals has been doing the research by reverse engineering the each module of CSME, e.g: the architectural summary, NSA’s hidden switch in CSME, IDLM module, etc. Open source brings the transparency doesn’t means the improvement of security. People can do the binary audit without source code like the community has been doing with CSME but it’s a time-consuming job. In the other hands, closed-source doesn’t mean it’s not secure. Intel CSMEv15 is a good example, which 1) integrated the modern mitigation (CET), 2) doing the fuzzing in the development process. These techniques can benefit both open source and proprietary projects.

Tooling?

• Get ME info( Bootguard included) at runtime: coreboot/util/intelmetool. This tools need access the info via iopl() so do it at first if you’re using PaX/GRsecurity: echo 0 > /proc/sys/kernel/grsecurity/disable_priv_io
• Disable ME features temporarily until power shutdown: me-disable
• ME code module removal and altmedisable/HAP bit enablement: me_cleaner

Tools	ME Type	Feature
me_cleaner	ME/TXE/SPS	Code module removal & altmedisable/HAP bit enablement
intelmetool	ME	Get info
me-disable	ME	HECI CMD
spsInfo	SPS	Get info
mei-amt-check	ME	Get info
mmdetect	ME/SPS	ME manufacturing mode detection
ifdtool	ME	altmedisable/HAP bit enablement, region adjustment. If ME modules are removed, their space could be spared for ‘bios’, and ifdtool could be used to adjust region boundaries.

intelmetool/spsInfo are implemented by mmap to dump ME/SPS info out of /dev/mem. HECI CMDs being reversed and me-disable implemented it based on mei_me LKM.

Conclusion

“For we wrestle not against flesh and blood, but against principalities, against powers, against the rulers of the darkness of this world, against spiritual wickedness in high places. — Ephesians 6:12”

The firmware security becomes more important than ever before and it may be different to other security fields but the methodology is pretty much the same. “Know your enemy” should always be the 1st priority. If the enemy could attack you, they would or maybe they did already. It doesn’t matter if they’re visible or invisible to you. This is a long-term fight. From enterprise security perspective, the future is depend on the wisdom of every CISO and security engineers.