Unpatched Linux Bug May Open Devices To Serious Attacks Over Wi-Fi (arstechnica.com) 21
Long-time Slashdot reader Kekke shared this article from Ars Technica:
A potentially serious vulnerability in Linux may make it possible for nearby devices to use Wi-Fi signals to crash or fully compromise vulnerable machines, a security researcher said.
The flaw is located in the RTLWIFI driver, which is used to support Realtek Wi-Fi chips in Linux devices. The vulnerability triggers a buffer overflow in the Linux kernel when a machine with a Realtek Wi-Fi chip is within radio range of a malicious device. At a minimum, exploits would cause an operating-system crash and could possibly allow a hacker to gain complete control of the computer. The flaw dates back to version 3.10.1 of the Linux kernel released in 2013...
The vulnerability is tracked as CVE-2019-17666. Linux developers proposed a fix on Wednesday that will likely be incorporated into the OS kernel in the coming days or weeks. Only after that will the fix make its way into various Linux distributions.
Nico Waisman, who is a principal security engineer at Github [and discovered the bug] said he has not yet devised a proof-of-concept attack that exploits the vulnerability in a way that can execute malicious code on a vulnerable machine. "I'm still working on exploitation, and it will definitely... take some time (of course, it might not be possible)," he wrote in a direct message. "On paper, [this] is an overflow that should be exploitable. Worst-case scenario, [this] is a denial of service; best scenario, you get a shell."
The article notes that the flaw "can't be triggered if Wi-Fi is turned off or if the device uses a Wi-Fi chip from a different manufacturer."
The flaw is located in the RTLWIFI driver, which is used to support Realtek Wi-Fi chips in Linux devices. The vulnerability triggers a buffer overflow in the Linux kernel when a machine with a Realtek Wi-Fi chip is within radio range of a malicious device. At a minimum, exploits would cause an operating-system crash and could possibly allow a hacker to gain complete control of the computer. The flaw dates back to version 3.10.1 of the Linux kernel released in 2013...
The vulnerability is tracked as CVE-2019-17666. Linux developers proposed a fix on Wednesday that will likely be incorporated into the OS kernel in the coming days or weeks. Only after that will the fix make its way into various Linux distributions.
Nico Waisman, who is a principal security engineer at Github [and discovered the bug] said he has not yet devised a proof-of-concept attack that exploits the vulnerability in a way that can execute malicious code on a vulnerable machine. "I'm still working on exploitation, and it will definitely... take some time (of course, it might not be possible)," he wrote in a direct message. "On paper, [this] is an overflow that should be exploitable. Worst-case scenario, [this] is a denial of service; best scenario, you get a shell."
The article notes that the flaw "can't be triggered if Wi-Fi is turned off or if the device uses a Wi-Fi chip from a different manufacturer."
I mostly try to use Atheros (Score:2)
Since they mostly try to support Linux properly.
But lots of the cheap USB dongles out there are rtl chipset...
FUD (Score:5, Informative)
See here, "news for nerds": https://hackaday.com/2019/10/1... [hackaday.com]
Re:FUD (Score:5, Informative)
Just like the sudo bug a few days ago, this requires a non-standard setup.
See here, "news for nerds": https://hackaday.com/2019/10/1... [hackaday.com]
The relevant part of the article:
"The catch with this bug is that before the vulnerable code is called, the driver checks whether the card is currently connected in p2p mode. Here’s the check in question if you’re interested https://github.com/torvalds/li... [github.com] . This means that rather than being vulnerable to attack any time your Realtek is powered on, you aren’t actually at risk unless you’re talking to another device using the p2p WiFi mode. In all the Linux WiFi work I’ve done over the years, I don’t think I’ve ever used p2p mode on a wireless card under Linux."
Re: (Score:2)
I don't know which chipset that Arduino, Raspberry and Chromecast use, but it seems to me that focusing strictly on desktop/server use cases is somewhat disingenuous.
Is it not true, that popular scenarios such as casting is exactly where p2p will be used?
Re: FUD (Score:2)
This is a valid question, but I don't think the Chromecast supports wifi-direct (p2p) at all. The only system that I know of that actually uses p2p WiFi is the Nvidia Shield controller, and Nvidia doesn't use Realtek wifi chips. I would be very interested in a case where Realtek is actually routinely used in P2P mode.
Re: (Score:2)
I don't know which chipset that Arduino, Raspberry and Chromecast use, but it seems to me that focusing strictly on desktop/server use cases is somewhat disingenuous.
Arduino doesn't have wifi or networking. They are typically paired with an ESP8266 chip, which uses the ESP8266 chipset.
Raspberry Pi uses the Broadcom chipset.
Chromecast uses a Marvel chipset.
Is it not true, that popular scenarios such as casting is exactly where p2p will be used?
Correct, that is not true. Casting does not use ad-hoc p2p wifi, they use infrastructure mode.
Re: (Score:2)
Raspberry Pi uses the Broadcom chipset.
Raspberry Pi uses Broadcom for the CPUs. They use Cypress for Wifi, e.g.: the 3B+ uses a Cypress 43455 for 802.11ac and Bluetooth 4.2.
Re: (Score:2)
e.g.: the 3B+ uses a Cypress 43455
That's actually interesting, and I suppose goes in favor of the point being made by the person I replied to.
At first I was almost certain you weren't correct as I firmly remember the "BCM" prefix on the wifi driver, even for the pi 3B.
Yet the set of numbers still slightly hit that "familiar" remembering feeling, so just looked it up instead of going on memory, just in case I was having a bout of digit-dyslexia or something.
Sure enough, the Pi 3 (original rev) uses chip BCM43438
The Pi 3B+ uses chip CYW43455
Re: (Score:1)
Re: (Score:1)
Try reading the entire sentence. Instant fix (Score:5, Insightful)
Nobody ever said "given enough eyeballs, all bugs are don't exist".
ESR said "given enough eyeballs, all bugs are shallow ... the fix will be obvious to someone".
Contrast the regular practice of Microsoft having to release second and third rounds of security patches to fix fucked up security patches because they didn't get it right the first or second time.
Contrast the Internet Explorer "vary bug", which was acknowledged by Microsoft and listed on their site for TWELVE YEARS before the appropriate person at Microsoft figured out how to halfway fix it.
On the day shellshock was discovered a thousand people were looking at the code. At least 150 of us were discussing it on one mailing list where Florian from Redhat quickly posted a proposed fix. A dozen other people suggested other, more complex fixes. Toward the evening of the second day and the morning of the third day, all the discussion (many eyes) found the problems in the more complex "fixes" and a consensus was reached that Florian's fix was the right way to go. He had posted his fix within a few hours. "The fix will be obvious to someone", it was obvious to Florian that time. The rest of us didn't immediately see it as clearly as he did, but with enough eyes there was somebody for whom the bug was shallow, the fix was obvious.
In this wifi direct case, the bug was shallow by nature - the fix was obvious to the first person to look at it.
Shallow does NOT mean "doesn't exist", it means you don't spend three weeks in deep thought trying to make sense of it.
Re: (Score:2)
While using WiFi peer-to-peer mode (wifi direct) (Score:2)
And while using WiFi P2P mode (aka WiFi Direct).
Here is the patch:
https://lkml.org/lkml/2019/10/... [lkml.org]
I've never used WiFi Direct, have you?
Re: (Score:2)
Re: (Score:2)
Subjective (Score:1)
An attacker getting a shell is better than them causing a denial of service? I donâ(TM)t think so.
Re: Subjective (Score:1)
looks like some bugs & vulnerabilities (Score:2)
Re: (Score:1)
I comp You.
The problem I see in this, is that somehow Governments seem to know these bugs beginning from the day zero.
And with this day zero I don't mean the day that The bug is spotted in the "wild".
The longer these will be in the "labs domain" not in the "wild", the longer they seem to be The Government asset.
These bugs eventually appear in the public Domain, and we eventually learn that Government operators have been exploiting them for years.
Now I would be totally cool with it,
if We knew that the Govern