How the Linux kernel balances the risks of public bug disclosure
Last month a serious Linux Wi-Fi flaw (CVE-2019-17666) was uncovered that could have enabled an attacker to take over a Linux device using its Wi-Fi interface. At the time it was disclosed Naked Security decided to wait until a patch was available before writing about it.
Well, it’s been patched, but the journey from discovery to patch provides some insights into how the Linux open-source project (the world’s largest collaborative software development effort) manages bug fixes and the risks of disclosure.
The Linux community worked hard last month to patch a bug in one of the operating system’s wireless drivers. The bug lay in RTLWIFI, a driver used to run Wi-Fi chips produced by processor manufacturer Realtek.
To be vulnerable to the bug, a device would have to include a Realtek Wi-Fi chip. These processors can be found in everything from Wi-Fi access points and routers through to some laptop devices explained the person that found it, GitHub’s principal security researcher Nicolas Waisman.
If a device does contain this chip, the consequences could have been serious, he told Naked Security at the time:
You could potentially obtain remote code execution as an attacker.
An attacker in radio range of the device could send a packet using a Wi-Fi feature called Wi-Fi Direct, which enables devices to talk to each other directly via radio without using a central access point. The attacker could add information to the packet that would trigger a buffer overflow in the Linux kernel.
Given that Realtek chips turn up in all kinds of equipment including routers and laptops, the bug seemed like a pretty big deal. It’s also an old one – it’s been in the Linux codebase since 2013.
Waisman – a security researcher of note with a good reputation and a responsible outlook – revealed the bug before the Linux team had fixed it, which had us scratching our heads and wondering why he’d do that.
On Tuesday 15 October 2019 he notified the group via security@kernel.org, a private email list. Two days later he released it to the public via Twitter on 17 October. It would be almost three weeks before the security team’s patch appeared in v 5.3.9 of the Linux kernel on 6 November.
Found this bug on Monday. An overflow on the linux rtlwifi driver on P2P (Wifi-Direct), while parsing Notice of Abs… twitter.com/i/web/status/1…
—
Nico Waisman (@nicowaisman) October 17, 2019
The answer to why he did that was that after he submitted the bug report to the private security@kernel.org mailing list, as per standard practice, the Linux security team sent the code for a proposed patch to the publicly viewable Linux Kernel and Linux Wireless mailing lists. Another public patch proposal followed two days later.
Waisman took the exposure of this code as a form of public disclosure. He told us:
As soon as it hits that mailing list, it means that everyone that is monitoring that mailing list knows about the vulnerability.
Waisman hadn’t produced exploit code for this bug. However, someone else might, he said. He worried that someone could reverse-engineer a zero-day bug by watching patch proposals like the ones flowing over the public mailing list.
By announcing it on Twitter, he was following what he believed were appropriate responsible disclosure guidelines, enabling a greater number of people to take avoidance measures (basically turning off their Wi-Fi functionality) until a patch became available. A report by Mitre (which maintains the CVE database) appeared on the same day with a link to the public mailing list, and the company assigned it a CVE (CVE-2019-17666).