Over the last year, there’s been a few vulnerabilities founds for the Zephyr Bluetooth stack:
CVEs are identifiers for vulnerabilities made public. It’s a system that provides a standardized way to identify and reference vulnerabilities or security issues in software and hardware systems. Each CVE entry is a unique identifier for a specific vulnerability or exposure. They allow everyone from vendors to consumers to track an issue, understand the impact, and ensure it is getting fixed.
A first look at the vulnerabilities may make you think that Zephyr’s Bluetooth stack is less secure than other stacks. After all, we’re seeing vulnerabilities. But what’s actually happening is that the Zephyr stack is getting reviewed. Because the stack is open source, that means the stack is easily available for anyone to review the code and find vulnerabilities, both attackers and defenders.
This debate of open vs closed source has raged for many years. Open-source code and stacks can make finding vulnerabilities easier. That enables even attackers. But there need to be defenders reviewing the code.
A few years ago, the Heartbleed vulnerability in the OpenSSL library was disclosed. The vulnerability was introduced accidentally a couple of years earlier. It’s not clear whether it was exploited before the bug was found and patched. There’s some evidence that it may have. The question at the time was how a vulnerability like this can be present in code that’s open source and used by billions of systems?
But if open-source stacks are vulnerable and make it easy for attackers to find exploits, one has to look at the flip side. Closed source stacks are tightly controlled, but attackers can still find ways to subvert them and find vulnerabilities. Binaries of stacks can be extracted and reversed. One such example are the TETRA standard crypto primitives which were closely guarded and were still extracted from hardware. The only people that can easily find and fix the vulnerabilities are the companies developing the code. This can be a small company with limited resources, or it could be a behemoth. Nothing guarantees that there’s any actual security work being done. After all, for many companies, security is an afterthought. For a Bluetooth stack that’s promoted as secure, that can be anything but.
One other advantage of open-source stacks is that the product developer has access to the source code and can evaluate the security, although whether one has the expertise to do so depends.
Even after a vulnerability is found, patching a product can be difficult. For closed source stacks, you often need the vendor to cooperate to make this happen. This can be delayed for many reasons, especially since security may not be the priority for the vendor. For open-source projects, patching can be done by the product developer.
To summarize, when choosing a Bluetooth or other stack, it’s critical to account for the support provided for managing vulnerabilities and handling them. Simply being an open-source project doesn’t mean that a stack is more secure, because this depends on an active effort to secure the stack. But it does have several advantages and opens the possibility for fixing vulnerabilities. On the other hand, a commercial stack from a reputable vendor may also be a better option, if they are security conscious.
All code has bugs. It’s critical to work on them and patch promptly and have a plan to patch.