Veel QNAP NAS-systemen kwetsbaar voor Linux Dirty Frag-lek

Reageer met quote

11-05-2026, 16:12 door _R0N_

Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Reageer met quote

11-05-2026, 16:59 door meinonA

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Reageer met quote

11-05-2026, 20:36 door Anoniem

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Reageer met quote

11-05-2026, 22:57 door buttonius - Bijgewerkt: 11-05-2026, 23:01

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server. Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Reageer met quote

Gisteren, 07:07 door Anoniem

Door buttonius:

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server.

Degene op wie je antwoordde (dat was ik niet) gaf al aan waarom dat niet klopt. Jij redeneert alsof die webserver geen bug kan bevatten. Dat kan wel. Als die bug een aanvaller in staat stelt om foute dingen te doen is dat een remote exploit, waarmee die toegang kan krijgen tot local exploits, zoals Dirty Frag. Je bent beter beschermd tegen aanvallers naarmate die meer beveiligingen moet zien te doorbreken. Het is onverstandig om te redeneren alsof de eerste beveiliging onfeilbaar is en wat daarna komt rustig lek mag zijn. Als de eerste dan toch niet onfeilbaar blijkt te zijn is het risico groot dat je meteen de pineut bent, en dat wil je niet.

Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Het is niet per se zo dat een HTTP-request naar een bestand op de webserver verwijst. Het is ook mogelijk dat alle requests, of alle requests onder een bepaald pad, of alle requests die aan een bepaald patroon voldoen, worden doorgesluisd naar code die vervolgens helemaal vrij is in hoe het de requests verder afhandelt. En helemaal vrij betekent dat er geen bestandsnaam in voor hoeft te komen, de enige vereiste is dat de webserver de gewenste response terugkrijgt van die code.

Kijk bijvoorbeeld naar de URL van de pagina waar we nu op zitten:

https://www.security.nl/posting/936111/Veel+QNAP+NAS-systemen+kwetsbaar+voor+Linux+Dirty+Frag-lek

Daar begint het pad binnen de site met "posting", dan volgt een nummer, dan de titel van de pagina. Als je die titel verandert in iets anders wordt nog steeds dezelfde pagina getoond. Kennelijk doet die tekst niets anders dan de URL voor mensen herkenbaar maken. Als je het nummer aanpast krijg je een andere pagina, of een redirect naar een specifieke reactie met dat nummer, of als je naar niets bekends verwijst de startpagina van de site. Kennelijk identificeert dat nummer wat je opvraagt. Is dat nummer een bestandsnaam? Dat is mogelijk, dat kunnen we van buiten niet zien (tenzij iemand een lek in deze site weten te exploiteren wellicht), maar het is ook heel goed mogelijk dat het een sleutel is waarmee de gewenste artikeltekst uit een databasetabel wordt opgehaald, de bijbehorende reactieteksten uit een andere tabel, en dat code op de server daar dynamisch de pagina uit opbouwt die we zien. Dan zit er geen bestandsnaam in de URL maar een sleutelwaarde.

Reageer met quote

Gisteren, 07:16 door Anoniem

Door buttonius:

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server. Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Dit ruikt naar flame bait.

Reageer met quote

Gisteren, 11:42 door Anoniem

Door Anoniem:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Er is geen andere bug in de webserver.

Reageer met quote

Gisteren, 11:47 door Anoniem

Door Anoniem:

Door buttonius:

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server. Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Dit ruikt naar flame bait.

Nee, alleen maar een junior die nog te weinig gezien heeft, en blijkbaar niet weet dat een webserver ook nogal eens scripten aanroept en niet alleen maar statische content terugstuurt .

Er komen toch vaak genoeg 'management url exploits' van allerlei platformen langs om niet meer zo'n naief vertrouwen te hebben in "de webserver doet strikte validatie en stuurt alleen bestand terug' maar ja ....

Reageer met quote

Gisteren, 11:48 door Anoniem

Door Anoniem:

Door buttonius:

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server.

Degene op wie je antwoordde (dat was ik niet) gaf al aan waarom dat niet klopt. Jij redeneert alsof die webserver geen bug kan bevatten. Dat kan wel. Als die bug een aanvaller in staat stelt om foute dingen te doen is dat een remote exploit, waarmee die toegang kan krijgen tot local exploits, zoals Dirty Frag. Je bent beter beschermd tegen aanvallers naarmate die meer beveiligingen moet zien te doorbreken. Het is onverstandig om te redeneren alsof de eerste beveiliging onfeilbaar is en wat daarna komt rustig lek mag zijn. Als de eerste dan toch niet onfeilbaar blijkt te zijn is het risico groot dat je meteen de pineut bent, en dat wil je niet.

Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Het is niet per se zo dat een HTTP-request naar een bestand op de webserver verwijst. Het is ook mogelijk dat alle requests, of alle requests onder een bepaald pad, of alle requests die aan een bepaald patroon voldoen, worden doorgesluisd naar code die vervolgens helemaal vrij is in hoe het de requests verder afhandelt. En helemaal vrij betekent dat er geen bestandsnaam in voor hoeft te komen, de enige vereiste is dat de webserver de gewenste response terugkrijgt van die code.

Kijk bijvoorbeeld naar de URL van de pagina waar we nu op zitten:

https://www.security.nl/posting/936111/Veel+QNAP+NAS-systemen+kwetsbaar+voor+Linux+Dirty+Frag-lek

Daar begint het pad binnen de site met "posting", dan volgt een nummer, dan de titel van de pagina. Als je die titel verandert in iets anders wordt nog steeds dezelfde pagina getoond. Kennelijk doet die tekst niets anders dan de URL voor mensen herkenbaar maken. Als je het nummer aanpast krijg je een andere pagina, of een redirect naar een specifieke reactie met dat nummer, of als je naar niets bekends verwijst de startpagina van de site. Kennelijk identificeert dat nummer wat je opvraagt. Is dat nummer een bestandsnaam? Dat is mogelijk, dat kunnen we van buiten niet zien (tenzij iemand een lek in deze site weten te exploiteren wellicht), maar het is ook heel goed mogelijk dat het een sleutel is waarmee de gewenste artikeltekst uit een databasetabel wordt opgehaald, de bijbehorende reactieteksten uit een andere tabel, en dat code op de server daar dynamisch de pagina uit opbouwt die we zien. Dan zit er geen bestandsnaam in de URL maar een sleutelwaarde.

Klets verhaal. Er is geen belangrijke bug bekend van hun webserver. SSH uitschakelen voor gewone gebruiker voldoet en de patch zal snel komen.

Reageer met quote

Gisteren, 13:53 door Anoniem

Door Anoniem:

Door buttonius:

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server. Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Dit ruikt naar flame bait.

Nee, alleen maar een junior die nog te weinig gezien heeft, en blijkbaar niet weet dat een webserver ook nogal eens scripten aanroept en niet alleen maar statische content terugstuurt .

Er komen toch vaak genoeg 'management url exploits' van allerlei platformen langs om niet meer zo'n naief vertrouwen te hebben in "de webserver doet strikte validatie en stuurt alleen bestand terug' maar ja ....

Ja hoor daar is ie weer, hij die de ander eerst kleineert (junior) en vervolgens denkt te weten wat een ander niet weet omdat het subonderwerp niet is aangeroerd. Verschrikkelijk nare manier van reageren. Voor jouw info. Mensen zijn klaar met windows 11 om heel veel redenen en HP ook: https://www.youtube.com/watch?v=BqtN0vsSnLQ

Reageer met quote

Gisteren, 14:33 door Anoniem

QNAP gebruikt blijkbaar een Linux kernel in haar eigen OS en vinden de severity maar moderate. Gewoon geen SSH voor normale gebruikers. Dat moet je zo wie zo niet doen want die NAS serveert eigenlijk alleen maar files via CIFS of NFS en webserver ook uitzetten.
Ik denk dat Windows 11 met WSL kwetsbaarder is maar daar hoor je niemand over.

Reageer met quote

Gisteren, 15:36 door Anoniem

Door Anoniem:

Door buttonius:

Door Anoniem 20:36:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Echt niet.
Met SSH toegang kun je je eigen code uploaden (als broncode en dan compileren) en vervolgens uitvoeren. Daarmee is zo ongeveer elke unix/linux systemcall beschikbaar.
Als je alleen tegen een webserver kunt "praten" heb je, om te beginnen, te maken met de (zeer grondige) input sanitation van die web server. Als je input daar doorheen komt was jouw input een geldig http request en de naam van een bestand op de server (en eventueel wat argumenten). De web server zal dan dat bestand voor je openen en het resultaat terugsturen. Je kunt dus alleen bestaande bestanden lezen of runnen en alleen voorzover de web server configuratie dat toestaat.

Dit ruikt naar flame bait.

Nee, alleen maar een junior die nog te weinig gezien heeft, en blijkbaar niet weet dat een webserver ook nogal eens scripten aanroept en niet alleen maar statische content terugstuurt .

Er komen toch vaak genoeg 'management url exploits' van allerlei platformen langs om niet meer zo'n naief vertrouwen te hebben in "de webserver doet strikte validatie en stuurt alleen bestand terug' maar ja ....

Ja hoor daar is ie weer, hij die de ander eerst kleineert (junior) en vervolgens denkt te weten wat een ander niet weet omdat het subonderwerp niet is aangeroerd. Verschrikkelijk nare manier van reageren. Voor jouw info. Mensen zijn klaar met windows 11 om heel veel redenen en HP ook: https://www.youtube.com/watch?v=BqtN0vsSnLQ

Niks mis mee om klaar te zijn met Windows .
Ik ga geen kwartier kijkend naar een pratende kop van een vlogger met een drama stem voor een vaag nieuwtje en een ontzettend clickbait titel (EXPOSED , STUNNING) . Enige wat nog mistte was "the REAL REASON" ) - maar blijkbaar doet HP iets anders met Windows installaties. Prima .

Het is alleen maar naief (en dom) om dan zo hard te geloven dat je maar onkwetsbaar bent als iets op Linux draait - of denken dat de webserver (of de CIFS server) ook bugvrij is.

Nagenoeg eerste hit als je even zoekt :

https://www.qnap.com/en/security-advisory/qsa-26-04 Apache bug.

Oh, "geen andere bug in de webserver" . Whataver.
Nog een stuk of dertig CVEs van dit jaar op de QNAP advisory page. Ik heb niet gekeken of en welke relevant kunnen zijn om (daarna) met copy fail ook privilege escalation te bereiken, maar haast zeker zit er wat tussen wat geschikt is.
Ik heb geen qnap, niet mijn probleem - wel een probleem als je denk dat (alleen) SSH access exploits mogelijk kan maken - haast altijd zijn er op een platform meerdere gaten .

Gewoon leerpuntje : een probleem komt zelden alleen, en erg veel hacks berusten uiteindelijk op een combinatie van een paar vulnerabilities - eentje om binnen te komen en een andere om meer rechten te krijgen . Soms een combinatie nog meer.
Je herkent de junioren of OS-fanboys gewoon aan het niet verder denken dan een recht toe recht aan exploit van de ene bug vanaf een volledige shell user .

Reageer met quote

Gisteren, 15:49 door Anoniem

Door Anoniem:

Door meinonA:

Door _R0N_: Ja zoveel doosjes met embedded Linux zullen kwetsbaar zijn.

Alleen maar als je al local access had. Zonder SSH- of Telnet-access is er niks aan de hand.

Natuurlijk wel - een (andere) bug in de webserver kan ook dezelfde exploit draaien .
Die webserver-user is net zo goed "local" .

Maar die webserver heeft geen bugs, dus nog niet relevant. Ik heb trouwens die webserver standaard uit. Admin via 1 gebruiker met ssh. Niet kwetsbaar dus. De meesten zullen dit consumenten apparaat alleen thuis in local netwerk draaien. Al helemaal niet kwedsbaar dus.

Reageer met quote

Gisteren, 17:13 door Anoniem

Niks mis mee om klaar te zijn met Windows .
Ik ga geen kwartier kijkend naar een pratende kop van een vlogger met een drama stem voor een vaag nieuwtje en een ontzettend clickbait titel (EXPOSED , STUNNING) . Enige wat nog mistte was "the REAL REASON" ) - maar blijkbaar doet HP iets anders met Windows installaties. Prima .

Het is alleen maar naief (en dom) om dan zo hard te geloven dat je maar onkwetsbaar bent als iets op Linux draait - of denken dat de webserver (of de CIFS server) ook bugvrij is.

Nagenoeg eerste hit als je even zoekt :

https://www.qnap.com/en/security-advisory/qsa-26-04 Apache bug.

Oh, "geen andere bug in de webserver" . Whataver.
Nog een stuk of dertig CVEs van dit jaar op de QNAP advisory page. Ik heb niet gekeken of en welke relevant kunnen zijn om (daarna) met copy fail ook privilege escalation te bereiken, maar haast zeker zit er wat tussen wat geschikt is.
Ik heb geen qnap, niet mijn probleem - wel een probleem als je denk dat (alleen) SSH access exploits mogelijk kan maken - haast altijd zijn er op een platform meerdere gaten .

Gewoon leerpuntje : een probleem komt zelden alleen, en erg veel hacks berusten uiteindelijk op een combinatie van een paar vulnerabilities - eentje om binnen te komen en een andere om meer rechten te krijgen . Soms een combinatie nog meer.
Je herkent de junioren of OS-fanboys gewoon aan het niet verder denken dan een recht toe recht aan exploit van de ene bug vanaf een volledige shell user .

Linux != windows. Zie patch dinsdag elke maand. 2 important of kritieke CVE's komt samen zelden voor.
QNAP zal mij ook een zorg zijn. Het is een GEEN open source maar een gesloten OS (QTS and QuTS hero) met een verbouwde Linux kernel. Daarnaast is het ook nog Chinees (Taiwan weliswaar). Dus een backdoor zal er wel inzitten. Mijn tip. Vanaf blijven. Liever https://rockstor.com/ (opensuse) Ik heb zalf altijd https://www.truenas.com/ gebruikt maar dat is Amerikaans.

Reageer met quote

Gisteren, 17:33 door Anoniem