Free and open is good. This idea promises transparency and unencumbered availability to all. Unsurprisingly, free and open-source software (FOSS) in embedded technologies is hugely beneficial: Integrating FOSS programs and libraries into products can reduce development overhead and accelerate time to market.
Developers win, manufacturers win, and — at least in an ideal world where companies honor their software license obligations — customers win. That’s why we see extensive use of FOSS within many product development organizations and why engineering teams around the world reflexively seek out open-source solutions when their new commercial offerings are in the pipeline.
But sometimes, “free” offerings carry a hidden price tag. This is absolutely true of FOSS.
While reaping the benefits of FOSS technologies, organizations eventually discover that they must pay off technical debts. This involves developing in-house expertise in third-party technologies, thoroughly auditing adopted code, and maintaining software as it inevitably diverges from its origins. This is also necessary, sometimes to a greater and more challenging extent, when licensing proprietary “black box” software solutions.
Despite the predictable expenses, there are many unknown variables. When integrating software into a broader product ecosystem, serious security vulnerabilities can arise and undermine not only the value provided by a product but also the confidence of end users. The best way to combat these issues is through planning and pursuing proactive measures, including efforts to identify and reconcile inconsistencies between adopted code and a product’s security objectives.
This is a big canvas: A malicious actor can successfully exploit weak links in a variety of areas based on a product’s operating environment, the partner ecosystem, and the way it gets used. When compromised products are deployed in an enterprise environment, the dangers can spread wide. It places critical business operations at risk and hurts both the brand and the bottom line. Compromised products in industrial systems, meanwhile, may carry even greater risks — potentially endangering the infrastructure, employees, and the public at large. Security flaws in consumer goods can lead to the theft of users’ personally identifiable information (PII), bank and credit card data, and more.
But again, there are all those benefits — and that’s why making open-source software safer and more secure for use in embedded systems is so vital. One particularly important weapon in this fight is the Open Source Security Foundation (OpenSSF), a cross-industry body dedicated to enhancing the security posture of open-source software. (My employer, NCC Group, is a founding member.)
Going a little deeper, let’s consider U-Boot, the open-source bootloader that’s been around for almost 20 years. It provides significant configurability, supports many architectures and reference design platforms, has a regular release cycle, and receives contributions from industry leaders. In many ways, it’s everything we would want in open-source software that’s relied upon to bootstrap Linux on countless system-on-chip (SoC) devices.
An example secure boot flow for U-Boot on an embedded platform. A security vulnerability at any one phase in the process can entirely undermine the entire chain of trust. (Image: NCC Group)
For our part, we’ve developed Depthcharge, a toolkit to help security professionals quickly find security holes in the modifications that engineering teams make to the U-Boot bootloader when creating their products and attempting to “lock down” their system. It shows how even innocuous configuration and implementation decisions can be abused to breach security. We documented and demonstrated how to use techniques integrated into the Depthcharge toolkit to bypass the security functionality in a smart speaker that includes a vendor-modified version of U-Boot.
Hardware configuration used to demonstrate an I2C-based bypass of boot-time security measures using NCC Group’s Depthcharge toolkit (Image: NCC Group)
These types of low-level attacks present opportunities for an attacker to extract user data and maliciously tamper with installed software. Fortunately, in our study, the vendor had already fixed the issue, leveraging an over-the-air (OTA) update mechanism to install fixes as soon as a user unboxes the device and sets it up for the first time.
Even though targeted physical attacks are not a major concern for most consumers, we must consider this threat scenario within the context of open-box returns, warranty handling, reverse logistics, and electronic-recycling services. If a device contains or processes sensitive user data, we all have a responsibility to protect that information at every stage in a product’s life cycle.
How can we make the open-source world more secure?
NCC Group’s investigation into a smart speaker’s bootloader offers just one example of how risk can emerge from businesses making inadequate investments into “paying back” technical debts while adopting third-party code. Whether it’s IoT offerings for the home, connected cars, or safety-critical industrial systems, ensuring that products are secure from prototype to end of life is one of many important challenges facing development teams.
It’s crucial for organizations to adapt third-party FOSS solutions to their own threat model and risk profile. Without this extra thought and investment, there’s a security debt — and it can be steep.
In the long run, avoiding and eliminating security debt always pays off. While accumulating technical and security debt helps engineering teams get products to market faster, even a limited investment in secure software integration processes can offer greater benefits and efficiencies in the long run. If vulnerabilities are not uncovered during the development phase, they will need to be remediated later during the security incident response stage — and that’s invariably more complex, time-consuming, expensive, and public.
Adopting FOSS programs, libraries, and tools effectively requires businesses to become experts in that software. Teams should evaluate how well they understand the code running in their products, the risks involved, and whether they need to invest more time to analyze and mitigate those risks. They should also carefully look at the product attack surface, threat model, and risks associated with their chosen software.
Investing time in the analysis and integration of open-source products also means that organizations are more likely to have the resources to communicate their findings and work more closely with the open-source community, which in turn delivers stronger fixes. In the larger sense, this will lead to the creation of more secure systems for everyone.
About the author
Jon Szymaniak is principal security consultant on the Hardware & Embedded Security Services team at NCC Group, as well as a former embedded systems software engineer. Since joining NCC Group in 2016, he has conducted security assessments for a plethora of targets including automotive ECUs, Android devices, a breadth of “smart home” products, and boot ROMs. His areas of focus include U-Boot, Linux, Yocto, and firmware reverse-engineering.
Advertisement
Learn more about NCC Group
