Today, a security issue was disclosed that had the potential to be the most serious Linux kernel security issue that Red Hat Product Security has dealt with in our 18 year history: BlueBorne. A flaw where a remote (but physically quite close) attacker could get root on a server, without an internet connection or authentication, just needing a system that has Bluetooth hardware installed and listening.
Bluetooth hardware is not particularly common on servers, and our Server distributions of Red Hat Enterprise Linux don’t enable Bluetooth by default, but we quickly turned our thoughts to the desktop. Laptops and desktop machines commonly have Bluetooth hardware, and Workstation variants of Red Hat Enterprise Linux enable Bluetooth by default.
Red Hat, along with other distribution vendors and the upstream Kernel security team, had been given one week notice of this issue to be able to prepare updates. During this period, upstream noted that this flaw should be caught if kernels are built with Stack Protection. Stack Protection has been available for some time, having been introduced in some distributions back in 2005. Although changing through the years, and most recently gaining a “strong” variant, the type of overflow in the Bluetooth stack was a straightforward large character buffer overflow, something that even the early Stack Protection feature catches. The Bluetooth stack flaw was introduced in 2009.
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). Certainly 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.
For Red Hat Enterprise Linux, we verified that Stack Protection was enabled on the affected functions, and paid attention to how the variable reordering placed the buffer on the stack. 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, 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.
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.
Source From: fedoraplanet.org.
Original article title: Red Hat Security: Kernel Stack Protector and BlueBorne.
This full article can be read at: Red Hat Security: Kernel Stack Protector and BlueBorne.