QNAP waarschuwt gebruikers voor privilege-escalationbug in Linux-kernel - update

QNAP meldt dat verschillende van zijn nas-systemen kwetsbaar zijn voor de eerder ontdekte Dirty Pipe-bug. Deze bug maakt privilege escalation mogelijk wanneer aanvallers lokaal toegang hebben tot het systeem. Het bedrijf komt later met patches voor zijn systemen.

QNAP schrijft dat verschillende van zijn systemen kwetsbaar zijn voor de bug, die eerder al werd ontdekt. Alle x86-nas-systemen die QTS-versie 5.0 of QuTS hero h5.0 of nieuwer draaien, zijn kwetsbaar. Datzelfde geldt voor 'bepaalde' Arm-modellen met die OS-versies. QNAP-systemen die QTS 4 draaien, zijn niet kwetsbaar.

De kwetsbaarheid zit in alle Linux-kernelversies vanaf 5.8. De bug maakt local privilege escalation mogelijk. Daarmee kunnen aanvallers met lokale toegang tot het nas-systeem commando's uitvoeren als root en daarmee eigen code injecteren. Het is niet mogelijk om de kwetsbaarheid op afstand uit te buiten.

De Dirty Pipe-kwetsbaarheid wordt aangeduid als CVE-2022-0847. Het betreft een fout in de pipebufferstructuur van de Linux-kernel, die aanvallers kunnen uitbuiten om naar pagina's in de page cache te schrijven en zo adminrechten op een systeem te vergaren. De update is inmiddels gepatcht in de Linux-kernel.

QNAP geeft de kwetsbaarheid een 'hoog' ernstigheidsniveau. Het bedrijf geeft aan de kwetsbaarheid te onderzoeken. De nas-fabrikant komt later met meer informatie en beveiligingsupdates voor zijn systemen die de kwetsbaarheid oplossen. Het is niet bekend wanneer dat precies gebeurt.

Update, 11.12: In het artikel is verduidelijkt dat het om een Linux-kwetsbaarheid gaat, en niet alleen een bug in QNAP-systemen.

Reacties (48)

[SunnieNL]

Dit is toch niet specifiek voor QNap?
Dit is dezelfde bug als die in de Linux kernel zat.
nieuws: Kritiek lek in Linux-kernel gevonden dat roottoegang mogelijk maakt

[AverageNL]

Inderdaad, dat mocht wel concreter benoemd worden in het artikel. Ik heb dat bij dezen verduidelijkt

[Yzord]

Wat ik niet snap is dat ze dit naar buiten brengen terwijl er nog geen patch is. Zo geef je potentiele hackers nog de kans om er gebruik van te maken.

Beter zou zijn om een patch vrij te geven alsmede de reden waar de patch voor is om zodoende druk achter de admins te zetten deze zsm te installeren. Nu heb je kans dat deze waarschuwing wel gezien wordt maar ook weer vergeten wordt omdat de patch er nog niet is.

[MoonRaven]

Als je dit niet meldt, dan zorg je ervoor dat beheerders helemaal geen actie ondernemen. Dit is juist een trigger om de rechten van iedereen na te lopen.

Als er bij een APK wordt gezien dat mijn remmen het niet goed meer doen en dat onderdeel niet hebben, dan heb ik liever niet dat ze het goedkeuren om later te zeggen "hey, je remmen zijn al een paar weken niet goed, kom ff langs voor onderhoud".

[Yzord]

Ik snap dat je dit moet melden, maar is het dan niet verstandig om dan meteen de patch aan de bieden? Want nu wordt het gemeld, maar geef je potentiële kwaadwillenden nu ook nog de mogelijkheid het te misbruiken. Imo lijkt mij dat een stuk veiliger dan het op deze manier brengen.

[Tjidde]

Dan kom je al snel op het probleem van Security through obscurity. Iets wat je eigenlijk gewoon niet wilt. Het feit dat een probleem niet publieke bekend is betekend niet dat er mensen zijn die er wel vanaf weten of er achter komen voor dat de update er is. Wat het voor een sysadmin juist moeilijk maakt om jezelf er tegen te beveiligen.

[bwerg]

Deze bug is nogal wijd verspreid en bij iedereen al lang bekend. Dus als QNAP zijn gebruikers niet informeert weten kwaadwillenden hier alsnog toch wel van, de enigen die het dan niet weten zijn dan de QNAP-gebruikers. Daar is niets veiligs aan.

Grote kans dat het meeste misbruik ook niet specifiek tegen QNAP-apparaten gericht is.

[tweaknico]

Het is mogelijk een beetje onder gesneeuwd door het hele Ukraine debacle.
Op ongeveer hetzelfde moment is ook deze Bug openbaar gemaakt.

Dus het is al breed bekend.

[Cybertinus994]

Het punt met deze bug is juist dat je rechten er weinig mee te maken hebben. Op Linux vlak kan je door deze bug in elke file schrijven. Ook als je er normaliter geen toegang tot hebt. Dat is juist wat deze bug zo eng maakt. Dus de rechten goed zetten in de Qnap webinterface gaat je niet beschermen tegen deze bug

[zenlord]

Nu kan iemand die een QNAP heeft de toegang naar het internet afsluiten.
Patchen is niet de enige mitigation optie.

[CH4OS]

Gezien de aanvaller lokaal toegang moet hebben, is internet afsluiten dus niet de remedie.

[zenlord]

Als iemand via ssh toegang heeft, dan kan die de exploit toch gewoon lokaal uitvoeren?
Internet afsluiten heeft dus wel degelijk nut. De SSH service afzetten nog meer.

[Tjidde]

Er zijn meer wegen naar Rome.

Plus echt kwaadwillende kunnen hier achter komen zonder dat QNAP het naar buiten brengt. Zeker aangezien het een Linux bug is en niet een QNAP specifieke. Nu kan jij als admin er voor kiezen om bepaalde restricties op netwerk niveau aan te brengen op je QNAP apparaten. Of zelfs te zeggen wij vinden de kwetsbaarheid te erg zolang er geen patch is, geen gebruik van het apparaat.

[CH4OS]

Wat ik niet snap is dat ze dit naar buiten brengen terwijl er nog geen patch is. Zo geef je potentiele hackers nog de kans om er gebruik van te maken.

Nu zijn de gebruikers ook gewaarschuwd. En in die hoedanigheid dus gewaarschuwd. Nu kunnen deze gebruikers eventueel maatregelen treffen om elk geval wat meer te voorkomen dat zij slachtoffer worden van deze bug. Dat liever dan gebruikers in het ongewis laten. Nu weet de klant dat aan een fix gewerkt wordt (al is het Linux generieke bug...).

Beter zou zijn om een patch vrij te geven alsmede de reden waar de patch voor is om zodoende druk achter de admins te zetten deze zsm te installeren. Nu heb je kans dat deze waarschuwing wel gezien wordt maar ook weer vergeten wordt omdat de patch er nog niet is.

Nu kan een klant in elk geval voorzorgsmaatregelen nemen ipv per se reactief hiervoor te kunnen handelen. Wat tot grote schade kan leiden.

[Reactie gewijzigd door CH4OS op 26 juli 2024 09:41]

[J_van_Ekris]

Wat ik niet snap is dat ze dit naar buiten brengen terwijl er nog geen patch is. Zo geef je potentiele hackers nog de kans om er gebruik van te maken.

Maar als beheerder weet ik nu waar ik op moet letten, en kan ik eventueel corrigerende maatregelen nemen als tijdelijke workaround.

Beter zou zijn om een patch vrij te geven alsmede de reden waar de patch voor is om zodoende druk achter de admins te zetten deze zsm te installeren.

Moet je die wel hebben. Volgens mij is het wachten op de Kernel developers.

[rbr320]

Moet je die wel hebben. Volgens mij is het wachten op de Kernel developers.

Nee hoor, zoals ook in het artikel wordt vermeld is deze kwetsbaarheid in de Linux kernel inmiddels gepatcht, dus het is momenteel echt aan leveranciers die gebruik maken van de Linux kernel, en ook aan de beheerders van Linux distributies, om een update aan te bieden. Voor de grote distributies zoals SUSE, Fedora, Red Hat, Debian, Ubuntu en afgeleiden is die er overigens ook al een paar dagen.

[.oisyn]

Het is alleen geen probleem in de QNAP software, maar in de gebruikte linux kernel, waarvan het bestaan al bekend was. Hackers wisten dus sowieso al van het probleem, en het heeft daarom niet zoveel nut om dit stil te houden, beter waarschuw je je klanten zodat ze mitigaties kunnen toepassen totdat QNAP zelf ook met een patch komt.

[inhico]

Het lek in de kernel is al langer/breder bekend, ook zonder dit bericht van Qnap.

[tweaknico]

De patch is er ook voor de kernel, maar ik denk dat QNAP dat nog door wat test straten heen moet halen.

[Tjidde]

Ik ken QNAP niet specifiek maar zou een oplossing zijn om zelf de kernel een update te geven? Of heeft QNAP een custom kernel ontwikkeld?

[fapkonijntje]

Is gewoon een Linux kernel. Komt vanzelf wel een update van, doen ze vaker bij Qnap.

[bilbob]

klopt, ik heb er twee van Qnap. De oudste is rond 2005 gekocht. Krijgt nog steeds updates.

[beerse]

Voor dit soort zaken en specifieke hardware is het beste de fabrikant te volgen. Als je zelf met kernels en zo aan de slag wilt, dan kan je beter zelf een nas opbouwen en daar een speciale nas-gerichte distributie op te installeren of eventueel zelf alles bij elkaar te zoeken.

Fabrikanten als qnap en synology hebben een goede reputatie. Zij melden issues met workarounds en komen later met updates/patches.

[guidogast]

Ik vind het heel netjes dat ze het goed aangeven en ook weer fixen. Precies zoals het hoort. Je kunt bepaalde dingen niet voorkomen, het is allesbepalend hoe je ermee omgaat en dat doet QNAP best goed al zeg ik het zelf.

[base_]

QNAP heeft in het begin nogal open instellingen als defaults gebruikt, daarmee waren ze een nogal makkelijk target. Ze wijn wel proactief met patches, en ik geloof dat ze nu ook standaardinstellingen beperkter instellen. Zou me ook niet verbazen als veel andere NAS systemen hetzelfde issue hebben.

[guidogast]

Ik heb zelf een QNAP, en je hebt nu een security app waarmee je precies kan zien waar jouw NAS niet goed beveiligd is. Hier worden ook de default ports meegenomen. Dus dat doen ze nu in ieder geval beter dan eerst inderdaad

[MazDaMan1970]

Als ik mij niet vergis heeft DSM (Synology) een oudere Linux kernel, die hier dus blijkbaar niet gevoelig voor is.

[J_van_Ekris]

Maar als het in de Linux kernel zit, hebben andere NAS leveranciers er dan ook geen last van?

[SunnieNL]

ligt eraan welke kernel die gebruiken. Synology zit in de meeste NAS systemen nog op kernel 4.4 en die is niet vatbaar.

[Verwijderd]

Ik ben benieuwd hoe lang het duurt voordat Synology bekend maakt dat ook hun NAS vulnerable is!

Want??

nieuws: Kritiek lek in Linux-kernel gevonden dat roottoegang mogelijk maakt

Edit: Blijkbaar is Synology niet vatbaar

SunnieNL in 'QNAP waarschuwt gebruikers voor privilege-escalationbug in Linux-kernel - update'

[Reactie gewijzigd door Verwijderd op 26 juli 2024 09:41]

[beerse]

In een andere reactie is gemeld dat synology kernels gebruikt die niet vatbaar zijn voor deze issues...

[peter-rm]

ook ars technica heeft er al aandacht aan besteed
https://arstechnica.com/i...y-vulnerability-in-years/

[iChaos]

Het artikel wekt de indruk dat er nog geen kernel is uitgebracht waarin de bug verholpen is. De website van de exploit https://dirtypipe.cm4all.com/ benoemt:

"The vulnerability was fixed in Linux 5.16.11, 5.15.25 and 5.10.102."

[Reactie gewijzigd door iChaos op 26 juli 2024 09:41]

[Dylan_R]

Ik heb wel het idee dat Qnap een beetje zijn merknaam aan het verliezen is.

-Edit. Laat maar dit is linux-kernel probleem

[Reactie gewijzigd door Dylan_R op 26 juli 2024 09:41]

[fapkonijntje]

Dit is gewoon een generieke Linux bug, dit zit in alles dat Linux gebruikt. Dus ook bij de concurrentie. Qnap is in dit geval extra aan het communiceren.

[CH4OS]

Wat ik van SunnieNL in 'QNAP waarschuwt gebruikers voor privilege-escalationbug in Linux-kernel - update' begrijp, is dat synology nog op de 4.4 kernel zit, waar deze bug niet in zit. Dus niet alle concurrentie heeft er last van.

[fapkonijntje]

Jeetje, je gaat er toch niet vanuit dat zo'n bekend merk op zulke antieke software draait.

[MazDaMan1970]

Stabiel is iets anders dan antiek . Bovendien brengt Synology regelmatig security-patches uit & worden zelfs zeer oude NASsen nog steeds ge-support.

[fapkonijntje]

Ja, wat dat aan gaat doen ze gewoon hetzelfde als de concurrentie. In NAS land bij de twee grote namen (Qnap/Synology) is het updatebeleid een keer géén issue. Het enige grote verschil tussen de twee is wel dat Qnap wat meer cutting edge bezig is met software en soms ook hardware en Synology met DSM wat langzamer ontwikkelt.

Zo kun je op een QNAP NAS met een ARM SoC gewoon docker gebruiken en kan dat bij Synology nog steeds niet. Ookal werken ze beide met dezelfde socs. Dat zijn van die dingen die mij dan weer qnap doen overwegen. Ik noem daarom ook Synology soms wat antiek en dat slaat ook wel een beetje op de denkwijze van het bedrijf.

[MazDaMan1970]

Ik heb beide; zowel een QNAP, als een Synology-NAS, maar beide draaien op Intel CPU's, dus wat docker betreft heb ik daar geen last van. Ik vind Synology meer volwassen & vooral voor de zakelijke consument is Synology de betere keuze, naar mijn mening. Ik heb wat dat betreft dan ook liever een OS met een oudere/ stabiele kernel, dan een cutting-edge/minder stabiele kernel.

[surfin]

Merk je als gebruiker van beide merken dan ook dat de QNAP minder stabiel is vs Synology?

[MazDaMan1970]

Beide zijn superstabiel. Wat performance betreft doen ze ook niet veel voor elkaar onder. Ik vind de webinterface van Synology beter ogen, meer consistent itt die van Qnap.

[Zwaai Haai]

Wat merk ik als niet Linux Tweaker, zeg maar een huis-tuin en keuken gebruiker van een Synology ervan dat er een oude Kernel inzit? okee, support komt ten einde straks. Maar wat missen de Synology NASsen nu qua funcitonaliteit?

[[Yellow]]

Als eindgebruiker mis je eigenlijk niet zo veel. Belangrijkste feature van nieuwere kernel is toch ondersteuning van de hardware. Wel is het zo dat nieuwere kernels wat sneller zijn in bepaalde gevallen. Security patches worden op alle LTS kernels gedaan dus daar mis je niets.

Als NAS gebruiker zou je (eventueel, in bepaalde toepassingen) dus een betere performance kunnen hebben.

[CH4OS]

De kernel is released als LTS, wat betekend dat de kernel zes jaar lang supported is. Released in 2016, dus dat betekend dat de kernel tot en met ergens dit jaar supported is.

Zie ook Linux kernel version history.

[Reactie gewijzigd door CH4OS op 26 juli 2024 09:41]

[beerse]

Mijn insteek is juist dat ze met dit soort informatie juist goed aan de weg timmeren.

Voor mij als qnap gebruiker/eigenaar is het mooi te zien dat mijn qnap TS 419P+ (pricewatch: QNAP TS-419P+ Turbo NAS) dus niet vatbaar is, ondanks dat ze begin dit jaar nog een update heeft mogen ontvangen.

[marcelnooijen]

Ahh shit here we go again