At my company, we have been using BalenaOS for our IoT product we are planning to launch to the market. We had a penetration test done on the device, and here is a vulnerability they found in the OS itself.
It seems that the key binaries run in hostOS are not appropriately hardened such as missing stack canaries and fortified compiler flags. This can lead the system to be more easily exploited using buffer overflows. unfortified_binaries.pdf (121.2 KB)
I could not find anything specific on the forums. Since these are run by the OS, I was a bit reluctant to alter them.
Was wondering if Balena team was made aware of this vulnerability. If yes, is a solution under development?
Otherwise have anyone tried to implement a “fix” for this?
Hello @mpous, We are using Raspberry Pi 4 (Compute module) and we are running balena OS version 2.75.0+rev1 with Balena Supervisor version 12.5.10.
I do know these are both outdated. I had a go at updating the OS this week, but that sort of wrecks our current code. Not by too much, but will require further dev work on our end.
Has there been any OS version changes that introduced a solution for this?
Hi Roland, let me try to address some of the concerns raised in those reports.
BalenaOS is a Yocto Project based distribution, and binaries are built following Yocto Project recipes. The Yocto Project community takes security seriously.
The reports raise concerns about security policies. BalenaOS is a lightweight hypervisor type of operating systems that runs containerized applications. These containerized applications can apply specific security policies to fulfill their needs, it’s not something that the hostOS should mandate.
About the busybox configuration, it raises a generic concern about the number of applets available without any specifics about attack vectors or vulnerabilities.
It feels that the report results are just generic best practice recommendations and the authors did not take the time to investigate the specifics of balenaOS and its use.
I’d like to follow up your initial request and would like to add some details about the findings in the report:
The penetration test finding about the missing canary or fortify flag on the balena-engine and balena-engine-init binaries is a false positive. These binaries are implemented in Go (Golang), and therefore, the canary and fortify flags are not relevant for them.
Background:
Stack Canaries: Go does not natively support stack canaries like C/C++ due to its different memory management and inherent safety features. Go’s runtime and compiler provide safety checks that reduce the risk of common vulnerabilities such as buffer overflows.
Fortify Source: This feature is available in C/C++ compilers like GCC and is designed to add buffer overflow checks to functions dealing with string and memory operations. Go inherently provides safety from such vulnerabilities by design. It does not use the C library functions that typically need Fortify, instead opting for safe built-in functions.
Since Balena uses Yocto, the resulting OS images follow default compilation flags that already take security into consideration. Unless a recipe overwrites these settings—which would be bad practice without a valid reason—the artifacts should be as secure as possible.
In summary, the specific security features of canary and fortify flags are not applicable to Go binaries, and the security measures provided by the language and the Yocto build system should ensure that the binaries are secure.