With the increase in sophistication of connected products and IoT devices, manufacturers face an increasing number of Common Vulnerabilities and Exposures (CVEs) reported.
The number of CVEs so far this year 12,678 (by September 8th) has already surpassed the total CVE count for 2019.¹
Out of the reported CVEs, remote code execution (RCE) vulnerabilities are considered the riskiest and scored with the highest severity. The reason is that remote code execution vulnerabilities enable the hacker’s process to carry out privilege escalation, get root privileges, and freely manipulate the device to his own objectives.
The hidden and visible costs of critical CVEs on a vendor’s business
The goal of the “Shift Left” security concept is to minimize the prevalence of vulnerabilities in shipped products. This concept was born out of the understanding that customers’ security expectations constantly grow and that fixing vulnerabilities in the field is costly.
When a vendor identifies a high-severity CVE in its product, or in a 3rd-party component it relies on, the race begins. In most cases, a hotfix should be provided within 30 days after the CVE was brought to the manufacturer’s attention, as per customer SLAs and white hat hackers’ common practices.
During the execution of this urgent procedure, the organization has to deprioritize mainstream activities to complete the PSIRT process: from investigating and determining mitigation, to allocating resources, developing a fix for each affected product, testing, and issuing a notification, and on to distributing the fixes.
All in all, such a random event has a significant monetary impact on the manufacturer’s business:
- Negative impact on R&D - To support the PSIRT process, in most cases, due to the tight time pressure, manufacturers’ best developers are assigned for the effort. That means key productive and creative talents are heads down to urgently create a hotfix rather than maintaining the company R&D plans, i.e., developing the key features of the next product.
- Product and revenues concessions - Diverting development and QA resources to reproduce the vulnerability, fix it, and test it on time, before the researchers publicly announce the CVE, creates delays in what those teams were planned to do, i.e. developing new features and test them, as part of the product roadmap. Such delays affect the product time-to-market and quality of the new features. In some organizations, such unplanned diversions are factored as part of the new product development plan, but it is clearly not desired as it has a high operational cost.
Senior engineering managers and Product Managers need to manage security concern crisis with key customers. In some instances, “bad timing” of vulnerabilities disclosed can delay or risk deals with security conscious customers – which are usually large accounts.
An internal cost analysis done at Microsoft2 has a few interesting numbers:
- $150K is Microsoft’s direct cost to fix a CVE (3:17 minute in the clip)
- $70M were spent by the company in 2018 to fix 468 CVEs (4:22 min)
- Growth in # of CVEs is steady over the years, with 70% being memory corruptions (7:11 min)
You can multiply $150K by the number of critical CVEs that your organization was accountable for last year, to quantify the CVEs cost to your company, not including the cost of product delays and lack of new features, which could improve the company’s top line.
Is there a way to avoid critical CVEs in products?
Manufacturers put a lot of emphasis on trying to reduce the number of critical CVEs via secure-development training. Code review best practices are widely implemented. Pen testing is performed on new products to expose vulnerabilities before products or new features are launched.
Result in the field indicate, however, that despite those efforts, critical vulnerabilities are unavoidable:
- The human factor: Development involves manual work, so even the top developers and best pen testers miss vulnerabilities in the product code.
- Software supply chain: The ability to develop sophisticated products in a short time is enabled by leveraging 3rd-party components. This, in turn, creates a more complex software supply chain, including various hardware drivers and open-source components. All have their own quality levels and risks, including hidden, critical, security vulnerabilities.
- More software: The unprecedented move to use more software at the expense of specialized hardware (virtualization) increases the software stack’s complexity (e.g., SDN and NFV), and the number of hidden security vulnerabilities in the code.
The chief goal of the Control Flow Integrity (CFI) defense is to maintain a device’s operational integrity under attack. It achieves that by embedding runtime integrity checks into the binaries, essentially locking down the processing and limiting it to the manufacturer’s intended function – to prevent device manipulation at runtime.
CFI-based protection provides a highly-optimized platform security capability to combat memory corruption vulnerabilities. For that reason, Microsoft3 and Google have selected CFI as their primary defense to protect their Operating Systems against exploits of hidden vulnerabilities in their code. This protection makes it significantly harder to execute arbitrary code through vulnerabilities such as buffer overflows.
How can CFI enable manufacturers to avoid the business impact of RCE vulnerabilities that are reported on their devices?
Should a remote code execution vulnerability be identified by the manufacturer, it can demonstrate to customers that the vulnerability cannot be exploited, thanks to the device’s embedded CFI software. In other words, CFI will render such vulnerabilities unavailable to the attacker looking to exploit them and gain control of the device.
Such security mitigation enables the manufacturer to avoid the urgent and costly processes of providing a hotfix to the bug. It can provide the hotfix as part of regular firmware, main release updates, as the device is self-protected against the RCE vulnerability exploit.
| Case study: Wind River Urgent/11 In August 2019 Armis reported4 on 11 vulnerabilities in Wind River’s VxWorks IPnet TCP/IP stack5, titled Urgent/11. Six of the 11 vulnerabilities were remote code execution – hence, classified as critical. The attack affected dozens of companies such as ABB, Abbott, Alcatel-Lucent, Avaya, Baxter, Bosch, Broadcom, Canon, F5, GE Healthcare, Medtronic, Philips and more. |
|---|
Wind River has issued a patch for VxWorks 7.0, but most of its install base is based on older versions. To enable its customers to prevent the exploits of the six critical RCE vulnerabilities, Wind River advised its customers to deploy Karamba’s XGuard CFI in their next software update. This safeguard makes the devices self-protected against exploits of those RCE bugs, although they might exist in the device code.
Conclusion
While minimizing the device attack surface during software development is important, reality shows us that manufacturers do ship products with hidden vulnerabilities. The cost of fixing them varies based on their severity, which dictates the urgency in the engineering organization. The CFI-protected device will suffer fewer Critical CVEs (such as RCE vulnerabilities), as the CFI protection mechanism will block the ability to exploit them, hence reducing the costly implications of with dealing with critical CVEs in the first place.
From the customers’ perspective, they receive a more cyber-resilient device of higher quality, which poses less risk, and which requires fewer patching cycles – an important factor in operationally-critical environments. This is one reason that runtime integrity protection has been added to recent standards and revisions such as NIST 800-53, Rev. 5, Runtime Application Self-Protection.
