Today, a security issue called BlueBorne was disclosed, a vulnerability that could be used to attack sensitive systems via the Bluetooth protocol. Specifically, BlueBorne is a flaw where a remote (but physically quite close) attacker could get root on a server, without an internet connection or authentication, via installed and active Bluetooth hardware.

The key phrase is “has the potential.” BlueBorne is still a serious flaw and one that requires patching and remediation, but most Red Hat Enterprise Linux users are at less risk of a direct attack. This is because Bluetooth hardware is not particularly common on servers, and our Server distributions of Red Hat Enterprise Linux don’t enable Bluetooth by default. But what about the desktop and workstation users of Red Hat Enterprise Linux and many other Linux distributions?

Laptops and desktop machines commonly have Bluetooth hardware, and Workstation variants of Red Hat Enterprise Linux enable Bluetooth by default. It’s possible that a malicious actor could use a remote Bluetooth connector to gain access to personal workstations or terminals in an office building, allowing them to gain root for accessing sensitive data or potentially causing a cascading, system-wide attack. This is unlikely, however, on Linux operating systems, including Red Hat Enterprise Linux, thanks to Stack Protection.

Stack Protection has been available for some time, having been introduced in some distributions back in 2005. We believe most major vendor distributions build their Linux kernels with Stack Protection enabled. For us, this includes Fedora Core (since version 5) and Red Hat Enterprise Linux (since version 6). With a kernel compiled in this way, the flaw turns from remote code execution to a remote crash (kernel panic). While having a physically local attacker being able to cause your machines to crash without touching them is bad, but it’s certainly not as bad as remote root.

Red Hat, along with other Linux distribution vendors and the upstream Kernel security team, received one week advance notice on BlueBorne in order to prepare patches and updates. We used this time to evaluate the issue, develop the fix and build and test updated packages for supported versions of Red Hat Enterprise Linux. We also used the time to provide clearly understood information about the flaw, and how it impacted our products, which can be found in the Vulnerability Article noted below.

Because Stack Protection works by adding a single check value (a canary) to the stack before the return address, a buffer overflow could overwrite other buffers on the stack before that canary depending on how things get ordered, so it was important for us to check properly. Based on a technical investigation we concluded that with Stack Protection enabled, it would be quite unlikely to be able to exploit this to gain code execution. We can’t completely rule it out, though, as an attacker may be able to use some other mechanism to bypass it (for example, if they can determine the value of the stack canary, maybe a race condition, combining it with some other flaw).

On some architectures, notably ppc64 and s390x for Red Hat Enterprise Linux, Stack Protection is not used. However the Bluetooth kernel module is not available for our s390x Server variant. And ppc64 is only available in a Server variant, which doesn’t install the bluez package, making it not vulnerable by default even if Bluetooth hardware happens to be present.

So if most distributions build kernels with Stack Protection, and Stack Protection has been available for many years before the flaw was introduced, where is the risk? Well, the problem is going to be all those kernels that have been built without Stack Protection turned on. So things like IoT devices that are Bluetooth enabled along with a vulnerable kernel compiled without Stack Protection will be most at risk from this flaw.

Regardless of whether you have Stack Protection or not, patch your system. BlueBorne remains an important flaw and one that needs to be remedied as soon as possible via the appropriate updates.

For Red Hat customers our page https://access.redhat.com/security/vulnerabilities/blueborne contains information on the patches we released today along with other details and mitigations. We’d like to thank Armis Labs for reporting this vulnerability.