Vault Labs, HardenedVault Limited
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.
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.
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.
|Version||1.x – 5.x||6.x – 10.x||11.x||12.x||15.x|
|Instruction set||ARC (32-bit)||ARCompact (32/16)||x86 (32-bit)||x86 (32-bit)||x86 (32-bit)|
|SPS||SPSv1.x||SPSv2.x – v3.x||SPSv4.x||SPSv5.x||SPSv6.x|
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.
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 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.
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:
From HardenedVault’s perspective, the 1st factor is easy to measure:
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.
Yes and no. There are a couple of options you have for CSME:
|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:
Yes, the equivalent of CSME is PSP (Platform Security Processor) on AMD chipset.
According to the public disclosures, we can have some important information during our assessment:
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.
|me_cleaner||ME/TXE/SPS||Code module removal & altmedisable/HAP bit enablement|
|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.
“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.