Given that they are network-accessible, BMCs present an attack surface. Which operating systems are hardened enough to be secure against malicious actors?
As I mentioned in a prior blog, Securing JTAG-based At-Scale Debug, Baseboard Management Controllers (BMCs) are the service management engines on virtually all of today’s servers. Operating out-of-band, they are often accessible over private network facilities via local or even remote management workstations. For a general overview of remote service management and its capabilities, see this AMI video of a UEFI Forum presentation: Out of Band BIOS Remote Management.
If a BMC can have its firmware remotely updated, and if the remote actor has the ability to change BIOS settings, update the OS, do backups and restores, etc., it must be absolutely protected. And adding JTAG access to the main CPU via the BMC, as with At-Scale Debug or At-Scale Test, has implications to the attack surface as well. Normally JTAG, being at its essence a physical interface involving five wires, requires physical access for it to be exploited, as per for example this blog: JTAG Explained by Senrio. It is pretty intuitive that, if you have physical access to that device, you own that device, as in the evil maid attack. But, if you can also virtualize that access, that contributes to make the case for absolute mitigation.
In general, there will always be trade-offs between a platform’s security and its ability to be debugged or tested. Even at the silicon level, there can be capabilities that are exposed on “pre-production” parts, but are not trusted within production devices; or, some on-chip functions, such as boundary scan, are exposed, but low-level BIST is not. It is essential to ensure that inadvertent backdoors are not created when enabling some functionality and disabling others. A good graphic of the paradigm is below:
There are many aspects to the security of a platform such as the BMC; too many to consider within this one article. Commercial BMCs have crypto engines and other hardware means to protect their boot mechanisms, secure access to external memory, avoid malicious code insertion, and so on. But, a key consideration worth discussing is the vulnerability of the platform operating system. How secure are the various choices for the BMC OS from hosting and running malicious code? Let’s consider some likely candidates:
- Linux
- WITTENSTEIN OPENRTOS
- Green Hills Software INTEGRITY RTOS
Linux
I won’t spend a lot of time talking about Linux as a BMC OS here; it’s open source, is a de facto standard for embedded systems, has plenty of tools and processor/platform support, and so on. Most BMC implementations use Linux; in fact, the OpenBMC initiative, the open source framework for BMC firmware, uses Linux as the foundation. Being open source, it has a huge community of engineers contributing to the kernel and ensuring that no insecure code or malware is inserted. Contributions are rigorously scrubbed for adherence to best practice coding standards, such as implementing bounds checks to avoid buffer overflows.
WITTENSTEIN OPENRTOS
OPENRTOS, and its cousin, SAFERTOS, are the open source commercial versions of FreeRTOS, which has enjoyed much widespread deployment – they claim > 113,000 FreeRTOS downloads in 2014 alone.
This is the OS presumably running on the Intel Innovation Engine, a small Intel architecture processor and I/O sub-system embedded into Intel’s next generation of server platforms.
SAFERTOS is certified to IEC 61508 (general functional safety), IEC 62304 (medical), ISO 26262 ASIL D (automotive), and others. One dimension of safety, of course, is security; not only should the software not fail, but it must not be hacked.
Interestingly, WITTENSTEIN also offer SAFERTOS CORE, that provides the complete functionality and API of SAFERTOS, but is designed to support embedded systems that need to consider safety, but don't require safety certification to international design standards such as IEC 61508 SIL3. In other words, safety is a consideration, but maybe not worth paying more money for if a certification isn’t required right away.
They don’t list ASPEED or Emulex (two of the more popular BMC models) as being supported on their website.
So, OPENRTOS is presumed to be very secure, based upon its open source nature and very large installed base.
Green Hills INTEGRITY
Green Hills positions INTEGRITY as the safest OS. Security from the ground up seems to have been an emphasis in the design of this OS over its history. Certainly, it has its fair share of certifications in the military, automotive and medical safety markets: FAA DO-178B, NSA EAL 6+, ISO 26262 (ASIL D), IEC 61508 (SIL 4), EN 50128 (SWSIL 4), FDA Class II and Class III, and IEC 62304, among others. Certainly, the claim of EAL 6+ (I’ve seen in some collateral EAL 7) is prodigious; by contrast, Windows is certified to EAL 4+.
INTEGRITY claims total platform security primarily by implementing a memory-partitioning architecture that isolates and protects embedded applications. Secure partitions guarantee each task gets the resources it needs to run correctly and fully protects the INTEGRITY operating system and native user tasks from errant and malicious code. It also guarantees the real-time access to resources of each application. So, in theory, applications running on INTEGRITY should be relatively immune to DoS attacks, trojans, viruses, and other malware.
Green Hills also offers the µ-velOSity RTOS for small embedded applications. I don’t have a lot of information on this OS, but as a small scheduler it seems that it might be relatively secure, in and of itself.
They also don’t list ASPEED or Emulex as being supported on their website.
The key difference between Green Hills and the other two options is that INTEGRITY is proprietary software, or closed source. Does that make it more secure, or less secure, than open source software? This makes for a philosophical debate that does not have any clear answer. Two different views of the subject are here: Why is open source software more secure? and Green Hills Software CEO Responds to Linux Security Controversy. Although I have not thoroughly researched this topic, I noted a balanced view from Wikipedia:
A study was done on seventeen open-source and closed-source software showed that the number of vulnerabilities existing in a piece of software is not affected by the source availability model that it uses. The study used a very simple metrics of comparing the number of vulnerabilities between the open-source and closed-source software.
Personally, I make the case for security through obscurity not being a meaningful means of mitigating attacks. BMC firmware designers cannot assume that, just because they are using a proprietary software platform, that hackers do not have access to the source code; nor can you assume that the object code cannot be reverse-engineered. Threat prevention and detection need to be built into the OS. And “goodness” metrics need to establish how strong or weak security is.
Next week, I’ll look into the security of those five JTAG wires at the silicon level. Since JTAG is so powerful, a means to protect the interface may in some cases be appropriate. What’s the best approach? Fusing? Challenge-response mechanisms? Encryption? Data locks? Others? Stay tuned!
In the meantime, check out ASSET’s take on chip and circuit board security: JTAG | IJTAG Semiconductor and Board Test Security (note: requires registration).
