These days, product security teams face incredible challenges when it comes to their vulnerability management program. Embedded software is more prevalent, made up of open-source software (OSS), commercial software and sometimes also proprietary code, and it is far more complex.
The result: increased attack surfaces, decreased control and far greater risk. What’s more, the number of vulnerabilities is growing; over 18 thousand CVEs were published on the NVD in 2020 alone!
To ensure their organisations’ perform with maximum effectiveness in the face of growing threats (in terms of volume and complexity), product security teams must scale their capabilities accordingly. This challenge comes with its fair share of time, money, and human resource implications.
How can product security teams know exactly what’s inside their software, which vulnerabilities are relevant to their product’s security, and how can they prioritize their work?
The solution - context-based analysis
Better understanding the context in which product components operate and how specific vulnerabilities might apply to them, is any product security team’s ticket to ride.
It’s important that you know everything you can about the product you choose to use. It is equally critical to understand the implications of not performing an analysis that takes the product’s entire context into account.
For instance, if a CVE is only applicable to 64bit systems (and not 32bit systems), knowing whether the analyzed product is one or the other, can help you avoid wasting valuable resources on vulnerabilities that may not be impacting your system at all.
At Cybellum, this knowledge and contextual understanding is obtained through the creation and leveraging of Cyber Digital Twins.
What are Cyber Digital Twins?
Inspired by Digital Twins, a Cyber Digital Twin is a detailed representation of a software component that provides insights into the composition, inner workings and context in which device software operates. Like their inspirational source, Cyber Digital Twins relate to machines, such as (but not limited to) vehicles, medical devices and industrial IoT equipment, focusing on the software that powers them.
It includes the software bill-of-material (also known as SBOM or C-SBOM), underlying hardware architecture, OS’s configurations, encryption mechanisms and keys, hardening mechanisms, full control flow, used API calls and more.
Armed with this enhanced understanding of the context in which product components operate, product security teams can filter out much of the irrelevant "noise,” thus shining a light on a subset of vulnerabilities that actually impact the product - and can risk its entire operation.
Doing so can yield dramatic results. For example, in one case, 90% of the vulnerabilities potentially affecting a particular component were filtered-out as irrelevant, enabling analysts to focus on just 33 relevant ones
Context-based analysis - practical examples
1) CVE-2019-19537 - USB Device Dependency: One of the most prevalent attack vectors in embedded software is through the USB interface. In this case, the issue is a condition bug, potentially caused by a malicious USB device in the USB character device driver layer, affecting the linux kernel.
With this in mind, the first step to context analysis is to check whether the USB ports are enabled. In doing so, CVEs can be filtered and support provided, based on devices that are USB-enabled.
2) CVE-2020-25212 - TOCTOU Mismatch in Linux Kernel: A time-of-check time-of-use (TOCTOU) mismatch was discovered in the NFS client code in the Linux kernel before version 5.8.3. It could be used by local attackers to corrupt memory, or possibly have unspecified other impacts, simply because a size check was being performed in fs/nfs/nfs4proc.c, instead of in fs/nfs/nfs4xdr.c.
We learned that this CVE is only effective if CONFIG_NFS_V4_SECURITY_LABEL is configured. As such the ability to filter the many CVEs related to Linux kernel based on compiled symbols is key.
Binary analysis is therefore key in this example. Ultimately, we were able to filter the Linux kernel CVEs by checking the compiled flags and eliminating those CVEs when missing specific flags inside the firmware.
3) CVE-2020-11899 - Ripple20: The Treck TCP/IP stack before version 184.108.40.206 has an IPv6 Out-of-bounds Read. This CVE is part of Ripple20 - a set of 19 zero-days that were discovered by JSOF experts in the Treck TCP/IP software library.
As a successful exploit could impact multiple parties, the first step to securing the software supply chain was to check if these CVEs matched the context of the device being analyzed, saving on resources otherwise spent on trying to fix irrelevant CVEs.
In this case, only firmware configured to use IPV6 communication was affected and required attention. But as the analyzed device was using IPv4, it was not affected by this specific CVE. As the network configuration cannot be known from solely checking the source code, here too, binary analysis was key.
Note that another possible context-aware analysis for this CVE relates to whether the kernel architecture was isolated from the application. In such a case, the vulnerability's impact could be far less severe, as this separation protected the entire system from malicious activity.
Why is binary analysis important for context-awareness?
Product security teams should leverage binary analysis to benefit from post-compilation software investigation that captures the full, broader scope of the component being tested, not just the ECUs/firmware source code. It covers OS related vulnerabilities, security issues with drivers, configuration issues, and more. Binary analysis also allows for fewer false positives when identifying vulnerabilities, leading to better time and resource management. Remember it's not just about the code; it’s also about how it is used. Relevance is key.
As demonstrated by the examples above, context awareness allows product security teams to prioritize courses of action that save valuable time and resources.
There are endless ways to leverage context-aware analysis to optimize CVE filtering: by CPU architecture, OS, commands/functions, and more. As such, infusing your vulnerability management practices with context-aware analysis brings value - and results - to any organization’s risk management endeavors.
Cybellum embodies context-aware analysis to shine a light on your software supply chain and protect your customers and your business. We set the new standard for product security at scale, eliminating cyber risk and facilitating compliance from the earliest stages of development all the way through integration and production, and when products are in operational use.
Discover how you can see all your software assets, understand the real impact of each vulnerability and mitigate security risks before they cause any harm. Talk to us today!
About the Author
Valentina is a Security Analyst at the Cybellum Research Lab. She works with customers and partners on embedded software security research, leveraging her Pen-testing and cyber-intelligence experience.