Github-medewerker ontdekt kwetsbaarheid in Realtek-wifidriver op Linux

Door een probleem in de Linux-drivers van Realtek-wifichips kunnen gebruikers mogelijk systemen van anderen op afstand laten crashen of overnemen. Door de bug kunnen kwaadwillenden een buffer overflow veroorzaken op nabije Linux-systemen.

De bug, die wordt aangeduid als CVE-2019-17666, werd geïntroduceerd in versie 3.10.1 van de Linux-kernel uit 2013 en is nog niet gedicht. Het probleem zit in de RTLWIFI-driver, die gebruikt wordt voor ondersteuning van Realtek-wifichips op Linux. De bug lijkt op zijn minst te kunnen zorgen voor een crash van het besturingssysteem. Mogelijk kunnen kwaadwillenden door de fout zelfs complete systemen overnemen.

De kwetsbaarheid kan in theorie worden uitgebuit wanneer een getroffen systeem in radiobereik van een kwaadwillende gebruiker is. Hiervoor is geen toegang tot het getroffen apparaat nodig, mits deze wifi aan heeft staan. De kwetsbaarheid maakt gebruik van de Notice of Absence-functie voor energiebesparing. Deze functie zit verwerkt in Wi-Fi Direct, een standaard waarmee twee apparaten via wifi met elkaar kunnen verbinden zonder dat daar een access point voor nodig is. De kwetsbaarheid is niet exploiteerbaar als de wifi op een apparaat uit staat. Ook systemen die een wifichip van een andere fabrikant bevatten zijn veilig. Ars Technica schrijft dat Android-apparaten met Realtek-chips mogelijk ook kwetsbaar zijn, op basis van twee verschillende links. Dit is overigens nog niet met zekerheid te zeggen. Google heeft hierop nog niet gereageerd, meldt Ars Technica.

De bug werd gevonden door Nico Waisman van Github. Nadat hij deze vond, deelde hij zijn ontdekking op Twitter. Volgens Waisman vormt deze bug een serieus probleem. "Het is een kwetsbaarheid die een [buffer] overflow kan veroorzaken via wifi op de Linux-kernel, mits je een Realtek-driver gebruikt," vertelt Waisman aan Ars Technica. Waisman heeft zelf nog geen proof of concept-aanval kunnen maken waarmee remote code execution mogelijk is. Wel stelt hij dat het exploitatie van de kwetsbaarheid op papier mogelijk is. In het ergste geval is dit een volledige denial of service-aanval; in het beste geval krijgen kwaadwillenden een shell, een omgeving waar gebruikers commando's en programma's kunnen uitvoeren.

Linux-ontwikkelaars hebben op woensdag een mogelijke oplossing voorgesteld. Deze wordt waarschijnlijk op korte termijn toegevoegd aan de Linux-kernel.

Reacties (33)

[wankel]

In het ergste geval is dit een volledige denial of service-aanval; in het beste geval krijgen kwaadwillenden een shell, een omgeving waar gebruikers commando's en programma's kunnen uitvoeren.

Is hier 'ergste' en 'beste' niet van plaats verwisseld? DoS is vervelend, maar laat je wel meteen weten dat er iets niet in de haak is; via een shell en privilege escalation is er geniepig meer schade aan te richten.

[derx666]

Ars Technica schrijft dat Android-apparaten met Realtek-chips mogelijk ook kwetsbaar zijn, op basis van twee verschillende links. Dit is overigens nog niet met zekerheid te zeggen. Google heeft hierop nog niet gereageerd, meldt Ars Technica.

Als Android devices mogelijk kwetsbaar zijn, hoe zit het dan met routers en access points? Volgens mij zijn er genoeg goedkope routers en ap's die realtek controllers gebruiken voor hun wifi, en tevens gewoon op een linux kernel draaien. Ik neem aan dat die dan ook mogelijk kwetsbaar zijn, waardoor de impact ineens nog een heel stuk groter is.

[_Pussycat_]

Ze hebben het over wifi-direct, dat is denk ik (met mijn beperkte netwerkennis) niet in gebruik op een router.

[The Zep Man]

Linux-ontwikkelaars hebben op woensdag een mogelijke oplossing voorgesteld.

Het betreft een patch die op twee plekken in de driver input validation toevoegt. Het lijkt er dus op dat één van de belangrijkste programmeerprincipes niet is gevolgd: valideer alle input.

[blorf]

Is alle mogelijke output van het apparaat wel volledig gedocumenteerd door Realtek?

[The Zep Man]

Het gaat er niet om welke berichten een apparaat stuurt of zou moeten sturen, maar om welke waardes je verwacht te ontvangen. Op dat laatste ga je filteren.

[blorf]

Je moet wel weten op precies wat je programmatuur moet kunnen anticiperen. Anders kunnen er onvoorziene situaties ontstaan.

[The Zep Man]

In dit geval was de maximale waarde P2P_MAX_NOA_NUM al gedefinieerd. De lengte van het bericht in noa_len (waar noa_num van afgeleid wordt) werd daar niet tegen gecontroleerd. De patch voegt deze controle toe.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:02]

[ajolla]

Je bedoelt met 'alle mogelijke output' misschien 'alle mogelijke output als gevolg van valide input'? Dat lijkt me namelijk wel. Het lijkt me goed om te valideren aan de hand van valide outputs. Niet aan de hand van allerlei troep die door ongedocumenteerde input veroorzaakt kan worden.

[aaahaaap]

De realtek drivers die van realtek afkomen zijn 1 grote bende, beste fix is nooit een realtek (USB) wifi chipset gebruiken.

[user029]

Heb je daar misschien enige onderbouwing/uitleg bij? Want ik heb het eerlijk gezegd nooit eerder gehoord(wat heel goed aan mij kan liggen, ik weet het).
Ik ben benieuwd of jij of nog meer mensen me t uit kunnen leggen.

Edit: danku!

[Reactie gewijzigd door user029 op 22 juli 2024 18:02]

[borft]

Klinkt als ongefundeerd geneuzel. Ik heb geen ervaring met rtl wifi drivers, maar wel met drivers voor rtl ethernet, en die drivers zijn prima, stabiel, snel en gewoon open source. Dit lijkt meer op een vrij standaard programmeerfout.

[HollowGamer]

Ik begrijp niet dat @aaahaaap word gedownmod, want hij heeft echt gelijk. Zeker als je zelf nooit met een Realtek WiFi chipset te maken hebt gehad, heb je echt geen idee hoe slecht het merendeel (niet) werkt op Linux.

Hier een overzicht van veel gebruikte RTL Wifi-chipsets:
https://github.com/search...8812&s=&type=Repositories - 128 repositories
https://github.com/search...8814&s=&type=Repositories - 25 repositories
https://github.com/search...8821&s=&type=Repositories - 84 repositories

Dat is echt een schrikbarend aantal, maar geeft aan hoeveel gebruikers problemen hebben willen oplossen die Realtek zelf niet opgelost kreeg. Daar zaten ook exploits tussen.

Het is dus echt geen geneuzel, het is echt bizar hoeveel puinhopen Realtek heeft gemaakt van hun drivers en daar kan ik helaas (ook) over meepraten. Mooi dat er inmiddels een alternatief is, die ook in de kernel zit, maar gezien de resultaten uit het recente verleden ben ik niet meer zo positief over Realtek.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 18:02]

[rbr320]

Niet geheel ongefundeerd. Realtek staat van oudsher niet bekend om zijn open source mindset en de eerste drivers voor Realtek chips in de Linux kernel waren dan ook geschreven door middel van reverse engineering, waren van slechte kwaliteit en boden slechte performance. Inmiddels is daar inderdaad, al dan niet met hulp van Realtek zelf, een hoop aan verbeterd. Waarschijnlijk is dit te danken aan het feit dat Realtek controllers inmiddels ook in servers worden gebruikt die veelal Linux draaien. Realtek chips hebben lang het stigma "consumententroep" gehad.

edit: en ik ben het in zoverre met @aaahaaap eens dat als ik de optie heb ik ook liever een netwerk controller van Intel gebruik.

[Reactie gewijzigd door rbr320 op 22 juli 2024 18:02]

[aaahaaap]

Sure. Als eerste ter volledigheid, mijn comment ging over de drivers die Realtek zelf heeft geschreven voor de USB wifi devices (geen idee wat de status is van de ethernet devices die @borft noemt, maar dat is niet relevant in deze context) die onderdeel zijn (of eigenlijk waren) van de Linux kernel.

Dan wat context: Realtek heeft/had tot nu toe weinig zin om zich aan de kernel interfaces te houden dus de drivers die ze hebben toegevoegd aan de kernel kopieren/herimplementeren een groot deel van de standaard kernel functionaliteit voor wireless devices. Als dit gedaan is doen ze hetzelfde voor hun volgende wireless chipset. Dit is uiteraard niet echt een goed model voor de gebruiker want bugs worden niet gefixt en userland tools moeten werken met de oude (of nog erger, aangepaste) interfaces die deze Realtek specifiek drivers gebruiken.
Er zijn dan ook talloze issues met Realtek USB wifi sticks, een korte zoektocht naar bijvoorbeeld https://www.google.com/se...x+8192cu+rtl8192cu+issues of https://www.google.com/se...i+8192cu+rtl8192cu+issues geeft al meer dan genoeg resultaten.

Ter illustratie de line counts van puur de C code van de verschillende drivers voor 1 chipset (de rtl8192cu). Dit is van kernel 4.19 voor de raspberry Pi:

# De realtek/rtl8192cu directory resulteert verwarrend genoeg in een module genaamd 8192cu (hier gaat het al mis )
# Dit is de driver die Realtek geschreven heeft
$ pwd
linux/drivers/net/wireless/realtek/rtl8192cu
$ wc -l `find -name '*.c'`
...
136803 total
# De rtwifi/rtl8192cu driver is voor zover ik weet door vrijwilligers/anderen gemaakt zonder hulp van Realtek
# Deze gebruikt de standaard kernel interfaces
$ cd ../rtlwifi/rtl8192cu
$ wc -l `find -name '*.c'`
...
7389 total

Zoals je ziet een redelijk verschil

Voor de volledigheid, de complete rtlwifi codebase die deze Realtek chipsets support

$ cd ../
$ pwd
linux/drivers/net/wireless/realtek/rtlwifi
$ find . -type d
.
./rtl8188ee
./rtl8192ee
./rtl8192cu
./rtl8723ae
./rtl8192ce
./rtl8192se
./rtl8821ae
./rtl8192de
./rtl8192c
./btcoexist
./rtl8723be
./rtl8723com

bevat minder lines of code dan de enkele rtl8192cu driver van Realtek zelf

$ wc -l `find -name '*.c'`
...
131048 total

Nog los van de problemen met de implementatie van Realtek is alleen al het feit dat er meerdere drivers zijn (er is ook nog een `rtl8xxxu` driver die in theorie ook zou moeten werken met deze chipset) al een belangrijke oorzaak voor problemen en verwarring bij eindgebruikers. Soms wordt de ene en soms weer de andere driver gebruikt on omdat deze door Realteks toedoen niet compatible zijn zorgt dit voor allerlei problemen.
M.a.w. als je als gebruiker een gegarandeerd werkend iets wilt hebben of als je eindgebruikers die een Linux device van je afnemen moet supporten zou ik aanraden een USB wifi stickje met een andere chipset te gebruiken.

Dan, specifiek over deze bug: De problematische realtek/rtl8192cu driver is gedropt in recente kernelversies en kijkend naar de voorgesteld patch https://lkml.org/lkml/2019/10/16/1226 wordt er een fix gedaan in de shared rtlwifi codebase. M.a.w. deze fout kwam dus niet door Realtek.

[edit] Hebben we hier geen code block (of beter nog Markdown) support?

[Reactie gewijzigd door aaahaaap op 22 juli 2024 18:02]

[Dreamvoid]

Dit is een open source driver, dus iedereen had deze bug kunnen zien en fixen.

[cdwave]

"Hij die zonder zonde is werpe de eerste steen."

[The Zep Man]

"Laten wij niet slap lullen in oud-Nederlands en ook geen stenen gooien."

Van drivers mag je iets meer kwaliteit verwachten dan de fouten die een stagiair zou maken met zijn eerste webapplicatie.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:02]

[Blokker_1999]

Vele ernstige lekken ontstaan door kleine vergetelheden. Soms ga je er gewoon vanuit dat een situatie niet kan voorkomen of dat deze ergens anders in de code wordt tegengegaan. Maar dat is niet altijd correct. Als niemand fouten maakte hadden we nu eenmaal ook geen bugs.

[Groningerkoek]

Iedereen maakt fouten, maar fouten die komen door aannames i.p.v. er door controle/verificatie feiten van te maken zijn het gemakkelijkste te voorkomen. Eigenlijk wil ik dat ook geen fouten noemen maar nalatigheid.

Beetje alsof ik naar bed ga en denk "ach, de vrouw zal de ramen wel dichtgedaan hebben" om er de volgende ochtend achter te komen dat dit niet zo was en de tv weg is.

[Reactie gewijzigd door Groningerkoek op 22 juli 2024 18:02]

[Groningerkoek]

hmm..

Dat is een bizarre omstandigheid.

[Verwijderd]

Sinds kernel 5.3.7, die vanmorgen uitkwam, heb ik ineens issues met de RTL8821CE van Realtek. Ik krijg deze niet meer aan de gang. Hebben ze dit tijdelijk dichtgezet?

[MiesvanderLippe]

In 5.3.5 word iets van RealTek genoemd;
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.5

In de versies erna vond ik niks op wifi, sdr, realtek of cve.

Edit: Die commit gaat over iets anders;
https://github.com/torval...dbbe43c284b2a3dcd030fd4ac

[Reactie gewijzigd door MiesvanderLippe op 22 juli 2024 18:02]

[cdwave]

Nadat hij deze vond, deelde hij zijn ontdekking op Twitter

Fijn dat hij alle exploit hunters even op het spoor heeft gezet.

[deadinspace]

Inderdaad, wat is er gebeurd met responsible disclosure?

[jeffrey-nl]

Hij had beter een pull request op Github kunnen openen met de fix, dat zou leuke reclame voor zijn werkgever zijn :-)

[HollowGamer]

Het verbaasd mij eerlijk gezegd niets. De Realtek WiFI Linux drivers zijn altijd slecht geweest, en veel ontwikkelaars hebben uiteindelijk zelf forks gemaakt om dingen (toch) werkend te krijgen. Zo is er een bug waardoor een dongle enkel op USB 2.0 snelheid werkt, waardoor dus de helft van de performance te halen is. Ook drops of geen verbinding kunnen maken met netwerken komt heel veel voor.

Dat deze (nieuwe?) driver het heeft gehaald in de Linux-kernel heb ik nooit begrepen, aangezien hun vorige drivers dus echt van bar slechte kwaliteit waren (veelal los zand/merge van vorige generaties, support voor oude kernels - wat overigens niet veel verschil maakte), met ook hierin beveiligingsgaten die uiteindelijk door externe (wel) zijn gefixed - maar nooit zijn opgepakt door RT.

Ook ik heb een tijdje speelt met de Realtek driver, maar het vervelende was dat RT geen sources vrijgeeft ookal zijn ze dit verplicht onder GPL. Of de source is zo oud en bevat(te) gigantisch veel bugs. Dus moest je opzoek naar fabrikanten die dit wel deden.. maar ook die sources waren oud of buggy.

Uiteindelijk maar een andere oplossing (media-bridge) of overstappen op Intel, want die werken wel prima out-of-the-box. Voor mij is het overigens ook een reden op Realtek te mijden, voor zowel LAN als WLAN. Al zie ik dat veel boards tegenwoordig dit ook doen gelukkig.

[Verwijderd]

Niemand had dit door van een driver die RTLWiFi heet ?

[uiltje]

Ooit hoopte ik dat static code analysis de meeste overflow bugs kan voorkomen. Helaas leven we nu al heel wat jaartjes verder, en blijkt keer op keer dat een taal / omgeving zonder impliciete boundary checks simpelweg niet veilig te krijgen is. Dat vind ik serieus jammer. Voor drivers kan ik me voorstellen dat het wel in C moet (hoewel GoLang bijvoorbeeld ook goed zou kunnen werken), maar ik kan er echt niet bij dat de taal nog gebruikt wordt voor hogere functies.

[JonKoops]

Kan me niet voorstellen dat Rust in 99% van de gevallen niet gewoon voor dit soort zaken ingezet kan worden.

[JonKoops]

Dit soort exploits lijken om de haverklap te gebeuren. Ik vraag me af waarom dit soort cruciale code niet in een memory-safe taal geschreven worden waar overflows gewoon niet kunnen.