Bug in Linux-kernelfilesystemlaag maakte verkrijgen van rootrechten mogelijk

Een bug in de Linux-kernel maakte het mogelijk voor gewone gebruikers om rootrechten te krijgen op de meeste distro's. De local privilege escalation-bug genaamd Sequoia zit in de filesystem-laag.

De kwetsbaarheid werd ontdekt door onderzoekers van beveiligingsbedrijf Qualys. Die tracken de bug onder CVE-2021-33909, maar noemen hem ook wel Sequoia. Het gaat om een bug in de bestandssysteemlaag van Linux. Als een aanvaller een bestandsstructuur met bepaalde lengte kan mounten en vervolgens verwijderen, ontstaat een mogelijkheid om een out-of-boundswrite uit te voeren waarmee een lokaal account code met rootrechten kan draaien.

De bug zit in de seq_file-interface. Die bevat een buffer en als die kan worden overschreden, kan de out-of-bounds ontstaan. Volgens de onderzoekers kan dat met een directorystructuur waarvan de lengte meer dan een gigabyte groot is.

De kwetsbaarheid zit in alle Linux-kernels tussen 3.16 en 5.13.x. In kernel-versie 5.13.4 is de bug opgelost. Daarmee zijn de meeste Linux-systemen kwetsbaar. De onderzoekers zeggen dat ze volledige rootrechten in ieder geval konden krijgen op Ubuntu 20.04, 20.10 en 21.04, en op Debian 11 en Fedora 34. In de recentste changelog van de kernel staat dat de bug is opgelost in versie 5.13.4. Die is door de meeste grote distro's inmiddels doorgevoerd.

Reacties (68)

[HollowGamer]

Ik begrijp nog steeds niet waarom distro's als Ubuntu de voorkeur geven aan ouder(e) kernels en vervolgens weer het grote gedeelte weer backporten. Waarom draai/push je niet gewoon de laatste stable zoals aangegeven op kernel.org?

Inmiddels doet Ubuntu het niet meer, maar voorheen hielden ze ook nog oudere kernels op je systeem. In mijn ogen prima als je tegen probleem aanloopt op een nieuwe kernel, maar daarvoor zijn er al longterm (LTS) versies voor beschikbaar. Ook de kernel zelf werd nooit geupgrade, of dit inmiddels is veranderd weet ik niet?

[Riesch]

Waarom draai/push je niet gewoon de laatste stable zoals aangegeven op kernel.org?

Omdat ook LTS versies issues hebben, Debian stelt stabiliteit boven alles, nooit problemen gehad met een kernel update. Nu heb ik Manjaro moeten kiezen vanwege een Ryzen laptop, en zelfs met de LTS kernel branch heb ik regelmatig kleine issues die ik met een eerdere kernel niet had.

Inmiddels doet Ubuntu het niet meer, maar voorheen hielden ze ook nog oudere kernels op je systeem. In mijn ogen prima als je tegen probleem aanloopt op een nieuwe kernel, maar daarvoor zijn er al longterm (LTS) versies voor beschikbaar. Ook de kernel zelf werd nooit geupgrade, of dit inmiddels is veranderd weet ik niet?

Er is niks mis met 2 oudere kernel versies op je systeem bewaren (storage is cheap en vanuit je bootloader even een oudere versie selecteren kan bij troubleshooten echt super zijn), voor servers en office desktops misschien niet extreem nodig. Voor laptops en splinter nieuwe desktop hardware, zie m'n eerste reactie.

[UPPERKEES]

Meer een algemene reactie...

Stabiliteit betekent dat er weinig veranderd. Geen API en ABI veranderingen. Het kan ook betekenen dat bugs en beperkingen bekend zijn, maar niet gefixed worden omdat die te disruptive zijn. Debian Stable betekent niet dat alles bug free is. Dus als iets niet (goed) werkt, zoals je WiFi, beeld, NVME of geluid en dat is een kernel issue. Dan hoef je ook niet te verwachten dat een kernel update dat gaat fixen. Die context mis ik vaak wel wanneer mensen Debian Stable als probleemloos beschrijven en de hemel in prijzen.

Ikzelf gebruik Fedora. Elke week wel iets van 3 near upstream kernel updates en veel algemene software updates. Maar ook Fedora heeft een stable release, dus geen API en ABI changes. Ik heb ook Debian Stable geprobeerd, daar had ik toch veel meer issues mee. Fedora is al ~8 jaar een breeze om te gebruiken. Andere vergelijkbare distro's vast hetzelfde.

[Reactie gewijzigd door UPPERKEES op 23 juli 2024 12:25]

[delphium]

Debian Stable betekent niet dat alles bug free is. Dus als iets niet (goed) werkt, zoals je WiFi, beeld, NVME of geluid en dat is een kernel issue. Dan hoef je ook niet te verwachten dat een kernel update dat gaat fixen.

Dat klopt gewoonweg niet. Als er echt een bug zit in software van Debian wordt er gewoon een patch uitgebracht waarmee het probleem wordt gefixed. Omdat Debian stable geen rolling-release is, heb je alleen niet altijd de laatste versie met de nieuwste features.

In de praktijk komt dat neer op dat je met jouw Fedora al lekker Gnome-40 draait en op Debian nog op Gnome-3.26 zit. Daar worden echter wel degelijk patches voor uitgebracht.

[UPPERKEES]

Dat is te overtrokken. Ja er komen patches uit. Maar die GNOME versie is al end of life. Cherry picking van patches wordt gedaan. Maar lang niet alles. Daarvoor zit je beter bij upstream. Net zoals met de kernel voor de voorbeelden die ik noemde. Debian Stable draaien betekent niet per definitie dat het bug free is, niet in die context van stable. De naam is ook verwarrend en geeft de verkeerde verwachtingen bij mensen die niet weten dat het alleen gaat om API en ABI changes die stable blijven. Met de meeste bugs in Debian Stable moet je gewoon mee leren leven en zoeken naar workarounds.

Fedora is ook geen rolling-release, die heeft ook stable releases Andere distro's die soortgelijk zijn ook niet rolling-release, maar genieten wel van upstream supported software. Daar gaat de boel wel beter van lopen in de zin van bugs fixen en hardware support.

[Reactie gewijzigd door UPPERKEES op 23 juli 2024 12:25]

[delphium]

Die Gnome versie is dus niet EOL aangezien hij 100% wordt ondersteund door een van de grootste Linux distro's. Dat er cherrypicking wordt gedaan voor patches is gewoon onwaar. Elke distro heeft z'n eigen patches bij release al. Daardoor lijkt het soms of een kwetsbaarheid niet wordt opgelost in Debian, maar dan blijkt simpelweg dat Debian gewoon niet kwetsbaar is.

Debian stable draaien betekent in de regel dat je een bizar stabiel en door en door getest systeem draait. De kans dat een update op Debian iets stuk maakt ik nagenoeg nul. Dat is waarom je, zeker op servers, kiest voor Debian of een andere fixed-release distro met een goede reputatie.

Als je een desktop of laptop hebt met hele nieuwe hardware, dan loont het zich om voor upstream distro's als Ubuntu en Fedora te gaan, hoewel je ook Debian Sid zou kunnen gebruiken.

Nogmaals, veiligheids updates worden ook op alle fixed-releases gewoon doorgevoerd. Dus niet alleen "API en ABI changes" zoals jij het noemt.

Zelf gebruik ik Gentoo, een rolling release distro, maar dat wil je echt niet op je server hebben draaien.

[UPPERKEES]

Die Gnome versie is dus niet EOL aangezien hij 100% wordt ondersteund door een van de grootste Linux distro's

Dat is ook erg overtrokken. De Debian developers zijn understaffed, zelfs security support wordt niet overal gedaan wegens tekort aan mensen. Er is ook een speciaal commando, dunno welke ook alweer, waar je een overzicht kan genereren welke packages geen security fixes meer krijgen. PHP is ook zo'n mooie, die is vaak ook al EOL in Debian. Sure je krijgt cherry picked fixes. Maar de ontwikkeling en maintenance zit in upstream releases.

Debian test hun packages goed ja. Fedora ook en elke andere grote distro ook Kans dat daar iets fout gaat is ook zeer klein. Ook omdat de developer hun eigen releases ook testen. Het is niet zo dat Debian de gatekeeper is van stability en je daarvoor Debian moet draaien.

Voor servers is Debian zeker weten een goede keus. Er verandert namelijk niet veel, dus kan je als het werkt er vanuit gaan dat het blijft werken. Net zoals met SUSE, RHEL, Rocky, CentOS, etc. Ook allemaal goede keuzes.

Nogmaals, veiligheids updates worden ook op alle fixed-releases gewoon doorgevoerd. Dus niet alleen "API en ABI changes" zoals jij het noemt.

Volgens mij heb je me verkeerd begrepen, of je weet niet wat API en ABI is? Er zullen juist geen API en ABI changes voorkomen in Debian Stable (of welke stable release van Fedora, Ubuntu, etc.). Security fixes worden wel uitgebracht ja. Dat doen ze wel degelijk, maar zoals aangegeven, ze hebben een tekort aan developers daarvoor. Dus super veel zou ik er niet op rekenen. Als je upstream support hebt, dan is je team je distro devs + de upstream devs. Een productievere combinatie.

hoewel je ook Debian Sid zou kunnen gebruiken

Heel slecht advies... Debian Testing en alles daarna breekt wel APIs en ABIs. Wat met transitions de boel per definitie sloopt. Daar heb je immers die releases voor, het is de speeltuin voor Stable. Ik ga toch ook niet Fedora Rawhide hier aanbevelen aan mensen?

[GeroldM]

Ben het wel eens met je stelling, maar heb een klein commentaar. Je geeft in je post aan dat de developers hun eigen code testen. Dat is per definitie de compleet verkeerde aanpak.

Het is veel beter om een developer een stuk code te laten schrijven, en daze door een test gooit die geschreven is door een tester (of andere developer in een tester rol) waarbij beiden dezelfde specificatie/user story hebben doorgenomen, maar niet met elkaar hierover hebben of mogen communiceren met elkaar..

Je zal verstelfd staan hoeveel verschil er zit tussen de interpretaties van beide personen. Ja, het is niet de snelste methode voor ontwikkeling. Je krijgt er echter wel hogere kwaliteitscode voor terug. Want een test die geschreven is door de auteur van de betreffende code test alleen op de scenarios die de auteuir kan bedenken. Dat kan heel copmpleet zijn, maar de kans dat er op die manier er toch wat doorglipt is hoger dan wanneer de code en test zijn geschreven door verschillende personen.

[N8w8]

Dat is vaak zo, maar niet altijd, de stabiliteit (en security) blijft leidend.
Toevallig weet ik deze bug, waardoor het betreffende pakket vrijwel onbruikbaar is.
Dat is op te lossen door gewoon te upgraden naar de nieuwste versie, maar voor Debian stable is dat te ingrijpend omdat dat ook een nieuwe Qt vereist.
Ook een andere fix proberen ze niet, ze laten die bug gewoon zitten waardoor dat hele pakket al 2 jaar onbruikbaar is, en ws zal blijven tot EOL.
Nou is dat geen belangrijk pakket maar t geeft wel aan waar de prioriteiten liggen.
Maar idd, als iets makkelijk te fixen is zonder dat het stabiliteit op andere vlakken treft (een nieuwe Qt is daarom not-done), dan wordt dat vaak wel gedaan.

(voor de leken; bij die link staat dus wel dat het gefixt is, maar die fix belandt niet in de huidige Debian stable, maar pas in de volgende. edit: En de bug was gevonden toen de huidige stable versie nog testing was)

[Reactie gewijzigd door N8w8 op 23 juli 2024 12:25]

[delphium]

Die bug trad op "Using Debian Buster/Testing with libc6 2.28-8".
Dat is dus niet Debian stable.

[N8w8]

Een Debian versie begint zijn leven als "testing", en zodra die stabiel genoeg is wordt die versie uitgebracht als de nieuwe Debian "stable".
Die bug was voor het eerst gevonden in Buster, op het moment dat Buster nog in het testing-stadium was.
Op een gegeven moment was Buster stabiel genoeg, en hebben ze die uitgebracht als de nieuwe Debian stable.
En de huidige Debian stable is nog steeds Buster, en die bug zit er nog steeds in.

[vlijmenfileer]

De naamgevingen van de Debian releases zijn wat onfortuinlijk.

Debian Stable gaat primair over stabiele software versies en interfaces "geen verrassingen", dus /geen of weinig updates/. Maar het krijgt wel degelijk alle belangrijke patches doorgevoerd, meest daarvan belangrijke security patches natuurlijk.

Debian Testing is wat met het modewoord van de dag een rolling release wordt genoemd; met gemak up-to-date genoeg v.w.b. software versies, en enorm stabiel /onder updates/. Een perfect, bijzonder stabiel, desktop OS. De naam Testing is voor dat gebruik misleidend, en moet je interpreteren als "Testing ground voor de Stable release".

Debian Unstable is waar je nog nieuwere versies van software krijgt, maar waar ook af en toe zaken stuk gaan /onder update/. Overigens nog steeds zo stabiel dat ik het IT'er geen probleem zou vinden te gebruiken. Het is met de normale interpretatie van het woord "onstabiel" echt een volledig misleidende naam.

Er is ook nog Debian Experimental, en nog wat etherische releases. Dat is pas het echte op het randje van de ontwikkelingen leven, met bijbehorende issues.


Ik denk dat als Debian de Testing release zou hernoemen, bijvoorbeeld naar "Daily" of "Rolling", dat dan echt hele grote groepen mensen die Debian niet goed begrijpen, of met kennis van Debian van meer dan tien jaar geleden rondlopen, het eindelijk eens zouden gaan begrijpen, en die release omhoog zou schieten in populariteit als desktop OS.

[Reactie gewijzigd door vlijmenfileer op 23 juli 2024 12:25]

[Superstoned]

Jup, klopt allemaal - stable betekend dat het niet veranderd, dus alle bugs blijven zitten. Niet dat er geen of zelfs minder bugs inzitten!

[Xander2]

Omdat ook LTS versies issues hebben, Debian stelt stabiliteit boven alles, nooit problemen gehad met een kernel update. Nu heb ik Manjaro moeten kiezen vanwege een Ryzen laptop, en zelfs met de LTS kernel branch heb ik regelmatig kleine issues die ik met een eerdere kernel niet had.

Ubuntu LTS 20.04 draait prima met alle features op een Ryzen 4800H met nvidia prime.
Hiervoor is het nodig de 5.8.0 HWE kernel te installeren (https://askubuntu.com/que...s-hardware-enablement-hwe).

[Riesch]

Thanks, maar ik ben geen Ubuntu fan. Zag al wel dat Debian Bullseye kernel 5.10 mee schuift.
Mocht ik Manjaro zat zijn kan ik nog altijd terug .

[Tozz]

Omdat je anders wijzigingen mee neemt. Je wil security patches redelijk zorgeloos kunnen installeren.

Stel, je hebt softwarepakket Foxgamer 1.0. Meegeleverd door Ubuntu. Jij programmeert ondertussen rustig verder aan versie 1.1 en 1.2. In 1.3 bedenk je dat je een aantal dingen anders wil doen, dus je herontwerpt alle commandline parameters en ook de werking is op sommige vlakken anders.

Nu blijkt in Foxgamer een security bug te zitten.. Iemand meld dat en jij maakt een patch voor je versie 1.3. Probleem opgelost!

Echter.. Als ik Ubuntu 25 draai, dan wil ik wel dat zolang ik versie 25 draai alles blijft werken zoals ik dat verwacht. Ik wil niet dat door een security update ineens mijn veelgebruikte Foxgamer pakket ineens totaal anders werkt.

Daarom port Ubuntu jouw fix in versie 1.3 terug naar 1.0, en geeft een nieuwe versie van 1.0 uit. 1.0-ubuntu1.

Bug is gefixt, maar de werking is nog zoals verwacht.

In praktijk is het nog een stuk lastiger. Stel dat je bij een security bug je Apache webserver zou upgraden van versienummer, dan vereist die misschien ook wel een nieuwere versie van OpenSSL. Maar je kunt die OpenSSL niet zomaar upgraden, want er is andere tooling die afhankelijk is van de vorige oudere versie van OpenSSL. Bovendien wil je misschien niet ineens dat TLS 1.0 en 1.1 niet meer werken door die nieuwere versie.

[wica]

Je kan toch bij Ubuntu er voor kiezen alleen de security patches te installeren. Zolang je op de zelfde versie van Ubuntu LTS blijft. Zou er geen breaking changes mogen zijn.

Ik laat mijn Ubuntu LTS servers als jaar automatisch security patches installeren, zonder problemen.
Leuke daarvan is, dat zodra ik via de ubuntu mailing list zie dat er een bug is, at ik weet dat mijn systemen binnen de 30min up to date zijn.

Alleen een reboot moet ik nog zelf doen.

[dmantione]

De reden is met name voor degenen die drivers extern van de kernel gebruiken, die zijn vaak niet 1-2-3 aangepast naar de laatste kernels en stabiliteit van de kernel is voor dat soort gebruikers dan ook gewenst.

[The Third Man]

Omdat 'stable' in die context slaat op wat de kernel-ontwikkelaars stabiel noemen voor hun eigen kernel (dus op zichzelf staand). Ze bedoelen er niet mee dat als jij die vervolgens in jouw X jaar oude distro gooit hij ook stabiel zal draaien, of dat al die andere software die nog ontwikkeld en getest is voor een oudere kernel dat ook zal doen. De kernel waarmee die oude distro indertijd is ontwikkeld is heeft daar een veel grotere kans op, want alle patches die daar nog op worden toegepast zijn security- of severe bugfixes en geen ingrijpende feature wijzigingen. Oftewel de distroboer kan met een relatief korte testcyclus een backport certificeren om te pushen naar de users, terwijl als je een hele nieuwe kernel gaat implementeren dan ben je eigenlijk een gehele certificering van een distrorelease aan het doorlopen, dat is de moeite niet waard.

[TrekVogel]

Er is al antwoord gegeven op het waarom dus daar ga ik verder niet op in. Je kunt in veel distro's vrij eenvoudig naar een nieuwere kernel schakelen. Dus als je graag een nieuwere kernel wil gebruiken, ik begrijp dat dat soms wenselijk is, dan kan dat gewoon.

In Mint kun je gewoon via de gui switchen van de standaard 5.4 kernel naar bijvoorbeeld 5.8 of 5.11.

[bouwfraude]

De kernel wordt in de Ubuntu varianten zeer regelmatig bijgewerkt. De vorige versie wordt bewaard, de voor-vorige versie wordt er met apt autoremove afgegooid.

[useruser]

Volgens de onderzoekers kan dat met een directory-structuur waarvan de lengte meer dan een gigabyte groot is.

lol

De leukste dingen worden ontdekt door de raarste acties uit te voeren op een systeem.

[Reactie gewijzigd door useruser op 23 juli 2024 12:25]

[SRI]

Ja maar was dit een rare actie of echt gevonden. De code is tenslotte allemaal publiekelijk toegankelijk dus ik kan me voorstellen dat iemand dus zag dat er een buffer was waarmee ze konden gaan rotzooien en uiteindelijk hierachter kwamen.

Vind het wel altijd weer knap hoe mensen zulke bugs vinden en weten te exploiteren. Echt een beroep apart als je het mij vraagt.

[TTIelu]

De hoeveelheid code in zo'n project, gecombineerd met wat een spaghetti het is, maakt het net onwaarschijnlijk dat de bug gevonden is door middel van "door de code te lezen".

De meeste bugs vandaag de dag worden gevonden door middel van fuzzing. Een geautomatiseerd proces van "willekeurige dingen doen met een systeem/programma" tot het fout gaat en vervolgens te kijken, door debugging en de code er naast te leggen, waar het precies fout is gegaan. Een voorbeeldje van een populaire fuzzer is AFL.

[uiltje]

Och, als je weet waar je naar zoekt dan is het ook weer niet zo lastig. Er zal maar een beperkte hoeveelheid code voor buffer handling zijn, en als je naar een buffer overflow aan het zoeken bent...

[Christoxz]

Echt een beroep apart als je het mij vraagt.

Dat is het ook en natuurlijk worden er genoeg bugs gevonden per toeval, maar er zijn zat onderzoekers die dagelijks opzoek zijn naar bugs om deze te exploiteren.

[Reactie gewijzigd door Christoxz op 23 juli 2024 12:25]

[MeMoRy]

Verschilt per bug. Hier zullen wel video's over komen.
Neem bijv de sudo(edit) bug. Die was wel gevonden na analyseren van de source. Maar hij had theoretisch ook gevonden kunnen worden door Fuzzing.
LiveOverflow heeft hier nu een interessante videoserie over.

[s.stok]

Zoals npm install

[MeMoRy]

Geweldig he?
Je file zelfs zou gewoon leeg kunnen zijn, want je slaat al je data gewoon op in het path
Mutability is een uitdaging, maar toch

[Reactie gewijzigd door MeMoRy op 23 juli 2024 12:25]

[pennywiser]

Als een kernel is gereleased onder een versienummer bv 4.19.194 zoals bij Debian en er wordt een fix in doorgevoerd welke door Debian is uitgebracht, dan is deze kernel toch niet meer precies zoals vanilla 4.19.194 of wel? Of zie ik dat helemaal verkeerd? Debian koppelt er ook zelf een releasenummer aan weliswaar, maar toch..

[The Zep Man]

Debian koppelt er ook zelf een releasenummer aan weliswaar, maar toch..

Het gebruikte veld daarvoor, CONFIG_LOCALVERSION, is precies daarvoor bedoeld. Er zijn dan ook weinig kant-en-klare kernels in distributies die volledig 'vanilla' zijn.

[rbr320]

Je hebt gelijk. Er zijn vrijwel geen Linux distributies die een 100% vanilla kernel distribueren zoals die door Greg Kroah-Hartman, de beheerder van de "stable" branch van de Linux kernel, wordt afgeleverd. Er worden altijd nog distro-specifieke patches op toegepast, waaronder backports van bugfixes. Dat zie je terug in het distro-specifieke versienummer van de kernel die je draait. Bovendien gebruikt iedere distributie zijn eigen kernel config om onderdelen zie ze niet nuttig vinden niet mee te leveren.

Als je op Ubuntu een vanilla kernel wilt draaien zal je deze uit de mainline repository moeten halen. Meer informatie daarover vind je hier.

[Reactie gewijzigd door rbr320 op 23 juli 2024 12:25]

[torretje2012]

kernel 3.16 heeft een releasedate van 3 aug 2014, heeft dus bijna 7jaar ongemerkt mogelijk misbruikt kunnen worden

[SunnieNL]

En daarmee wordt direct al het commentaar de kop in gedrukt dat normaal bij veel van dit soort bugs in Windows wordt gemaakt: dat Open Source veel veiliger is omdat er heel veel mensen naar kijken en beveiligingsbugs snel worden opgemerkt.

(wat ik overigens al jaren bestrijdt, dat open source alle code op straat heeft liggen wilt gewoon niet zeggen dat het daarmee veiliger is en er minder grote beveiligingsbugs in zitten dan in Windows)

[delphium]

Nee, maar een geschreven patch voor een probleem wordt wel direct door duizenden doorgelicht. De kans dat zo'n printer-nightmare, die maar blijft dooretteren, op Linux voorkomt is daarmee wel een stuk kleiner.

Aan de andere kant: er wordt vaak gezegd dat "security by obscurity" een slecht idee is, maar toch is dat iets waar een systeem als Windows best profijt van zal hebben.

[SunnieNL]

Maar waarom heeft dan niemand in 2014 bij de code verandering het probleem niet gezien, toen die duizenden mensen ook naar die verandering keken? Of zullen er gewoon geen duizenden mensen de code doorpluizen, zoals jij denkt? Ik betwijfel dat namelijk. Ik gok dat het een man of 10-100 zullen zijn, maximaal. Je moet namelijk wel bepaalde kennis hebben om te snappen wat er staat en om bepaalde fouten erin te ontdekken.

[delphium]

Maar waarom heeft dan niemand in 2014 bij de code verandering het probleem niet gezien, toen die duizenden mensen ook naar die verandering keken?

Destijds zullen er inderdaad slechts enkelen naar de code hebben gekeken. Ik heb het echter over patches. Die liggen veel meer onder een vergrootglas, zeker als het een flinke bug betreft. Ook zijn er veel securitybedrijven die er meteen bovenop springen om te kijken of er nog meer valt te exploiteren. Dat zijn hoe dan ook veel meer mensen dan bij MS beschikbaar zijn om naar die code te kijken.

Nee, open source is niet per definitie veiliger dan closed source, maar het omgekeerde is evengoed waar.

[Jogai]

Met deze redenering bewijs je nog steeds niet dat de stelling onwaar is. Beide kampen hebben dus een X aantal bugs die nog niet zijn gevonden. De redenatie is dat dit bij Open Source dus lager is. Die redenering weerleg je niet doordat er een bug openbaar komt.

De achtergrond is natuurlijk dat software waarvan de code niet openbaar is lastiger te doorzien is waardoor de werking en daarmee de mogelijke bugs daardoor minder zichtbaar zijn. Volgen mij is de stelling zoals die ooit is neergezet wel genuanceerder, namelijk met een voorbehoud dat er genoeg ogen op gericht moeten zijn.

Dus je laatste stelling klopt wel. Code is niet ineens bugvrijer omdat het open is. Maar in het conctrete gevan Linux vs Windows gaat het niet op omdat linux daadwerkelijk meer aandacht krijgt van beveiligings experts, en omdat er meerdere serieuze bedrijven zijn die dit kritisch bekijken (denk aan oa redhat etc.).

[Mellow Jack]

Krijgt Linux dan meer aandacht of krijgen de specifieke, veelal populaire enterprise (en afgeleide) dan meer aandacht? Natuurlijk pakt Linux in de breedte daar ook wel de vruchten van maar niet in absolute zin....

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 12:25]

[Jogai]

Volgens mij mist het woordje 'distro' in je zin.

Maar ja, daar heb je gelijk in. De kernel krijgt best wat aandacht, maar al die tooltjes van de honderden distro's niet, dus dat kan best een attack vector zijn omdat voor die tools het aantal kritische mee-denkers/-kijkers maar beperkt is.

[unglaublich]

Deze fixes worden "gebackport" naar "oudere" Linux kernel versies zodat bij de volgende security update van ondersteunde OSen de bug opgelost wordt.

Bijvoorbeeld voor Ubuntu versies: https://ubuntu.com/security/CVE-2021-33909

[MeMoRy]

Dan moeten de distro nog steeds deze updates doorvoeren. Afaik gebeurd dat niet automatisch, en gaan bij distro's oudere versies nog wel eens uit de support.

[BoAC]

Ik zie eigenlijk niet hoe dit actief misbruikt kan worden op bijvoorveeld hosting systemen. Een proces moet eerst de structuur aanmaken, daarna opnieuw mounten.. enz

[Twilkie]

Ubuntu

Lokaal draai ik 21.04, die lijkt reeds gepatched.
Voor enkele servers die ik heb op 20.04 lijkt de patch nog niet beschikbaar, ook niet via livepatch.

Update: Ondertussen wel beschikbaar en geïnstalleerd.

[Reactie gewijzigd door Twilkie op 23 juli 2024 12:25]

[Jonathan-458]

Betekend dit ook dat vrijwel alle NAS'en Linux based routers vatbaar zijn voor dit lek?

[Jan Onderwater]

Linux is volwassen geworden, het heeft de zelfde problemen als BSD, Windows, MacOS, etc.
Daar linux in miljarden apparaten wordt gebruikt als OS, waarvan de meeste mensen geeneens weten dat er een OS op draait (van Afstandsbedieningen tot Vaatwassers, van Televisies tot Digitale radios) is dit wel een risico daar steeds meer van deze apparaten met het internet verbonden zijn. Vaatwassers niet zo snel, maar de afstandsbediening van mijn Amazonbox of mijn Printer bijvoorbeeld wel, via het locale netwerk.
Zou eigenlijk bij wet verplicht moeten zijn dat fabrikanten security patching uitvoeren en dat gedurende de verwachte levensduur van apparaten. En dat geld natuurlijk niet alleen voor Linux en haar varianten. Het issue met linux is alleen dat het op heel veel apparaten draait waarvan de meeste mensen geen idee hebben dat er een OS in zit.

[djexplo]

Vaatwassers niet zo snel

Van de vaatwasser in de winkel heeft ongeveer 15% van alle vaatwasssers een Wifi aansluiting. Daarnaast is er nog zo'n 10% die officieel geen Wifi heeft, maar de service-engineer wel draadloos kan uitlezen.
In het hoge segment heeft waarschijnlijk in enkel jaren 100% een wifi aansluiting.

[PageFault]

Niet alles wat jij beschrijft draait Linux, de meeste printers hebben gewoon VxWorks en de meeste afstandbediening (Harmony daargelaten) zijn domme afstandbedieningen waar geen enkele intelligentie in zit. Ook in een vaatwasser zit een eenvoudige state machine, TV's (bestaan die nog niet-smart?) zijn altijd wel rijkelijk voorzien

Linux is al langer volwassen en heeft ook al langer last van lekken, net zoals elk ander OS.

Hoewel ik deze nog niet eens zo heel erg vind. Dat mounten moet je dan maar even toestaan voor externen. Vergeleken met de root bug van macOS een paar jaar geleden, is dit een niemandalletje.

[Reactie gewijzigd door PageFault op 23 juli 2024 12:25]

[Jan Onderwater]

Mijn koelkast draait linux

[PageFault]

de meeste koelkasten niet Vaak zit er niet eens een chip in...

[Jan Onderwater]

Je snapt het punt echt niet. Geeft niet, maar wat doe je dan op een IT forum?

[PageFault]

Ik vraag me af wat jij op een IT forum doet met domme koelkasten. Maar ik vermoed dat jij dat ook niet kunt uitleggen.

[r03n_d]

Linux is volwassen geworden, het heeft de zelfde problemen als BSD, Windows, MacOS, etc.

Ik vond het dan ook heel bijzonder om te lezen dat iemand hier recentelijk nog beweerde dat Linux altijd veel veiliger zal zijn en blijven door de opbouw/werking van het OS en package managers. Dat kan misschien in essentie wel zo zijn, maar m.i. is het een kwestie van tijd.

[delphium]

Verschil is wel dat in Linuxland bug vaak razend snel gepatcht worden en dat er ook direct duizenden mensen naar die specifieke patch kijken. Meestal zijn daardoor bugs ook definitief opgelost.

Ik ben zelf ook van mening dat Linux heel erg veilig kan zijn. Veiliger dan MacOS of Windows. Dat heeft vooral te maken met de eenvoud van het systeem en inderdaad de package manager die standaard alleen geverifieerde software installeren. Verder heb je veel meer keuze in wat je wel of niet wilt op je systeem.

Een en ander gaat natuurlijk alleen op als je verder geen domme dingen uithaalt op je systeem. Enige basiskennis is dus wel vereist.

[Jan Onderwater]

Er verschijnen patches, maar die moeten wel geïnstalleerd worden, en als een apparaat dat niet zelf doet, blijft de bug. Of denk jij dat mensen hun apparatuur regelmatig zelf patchen?

[delphium]

Nu haal je natuurlijk dingen uit de context. Als Windows veel op IOT-devices gebruikt zou worden, dan heb je exact hetzelfde probleem, dat mensen niet patchen. Het gaat er natuurlijk om dat de patches wel snel beschikbaar zijn.

Ik reageerde op @r03n_d :

Ik vond het dan ook heel bijzonder om te lezen dat iemand hier recentelijk nog beweerde dat Linux altijd veel veiliger zal zijn en blijven door de opbouw/werking van het OS en package managers.

[Jan Onderwater]

Correct, maar dat veranderd niets aan het issue

[GeroldM]

Op een Ubuntu Server LTS editie is het een kwestie van: sudo apt-get update && apt-get upgrade

Even dat uitvoeren en een minuut of wat later is je systeem up-to-date met de laatste patches. Ligt er natuurlijk aan hoe snel je internet verbinding is en in de mate hoever je achterloopt qua patches.

Maar doe dit dagelijks en na een dag of wat neemt het amper een minuut in beslag.

Bovenstaande geeft aan dat het veel minder moeite kost om een Linux systeem up-to-date te krijgen en/of te houden dan Windows servers. In mijn omgeving draaien er Windows werkstations, Windows servers, Linux servers, Linux werkstations en een "verdwalde" FreeBSD server. Drie keer raden welke servers/werkstations significant meer tijd aan onderhoud vergen. Tip: gok niet op Linux of FreeBSD.

Linux kan net zo onveilig worden geconfigureerd als Windows. Windows kun je net zo veilig configureren als Linux. Doe je dit, dan zul je zien dat je een enorme hekel aan Windows krijgt en Linux veel prettiger vind werken.

Ga vooral eens aan de slag in een Windows installatie waarvan de ACL's actief gebruik maken van 'Deny'. Windows is nu veel veiliger geworden, echter vervloek jij als gebruiker die Windows ervaring. Al na 5 minuten vergeet je all P.C-regels die je toe zou passen in je gevloek. Sterker nog, je onverbloemde getier zal menig schipper als te grof worden aangemerkt.

Gebruik je Windows en Linux met hun standaard instellingen, dan is Linux zeer zeker niet zonder fouten, maar wel degelijk veiliger dan de standaard ingestalde Windows. De kunst is dus de balans vinden in gesloten en open besturingssystemen.

Wat jij en ik onder de term "veiliger" verstaan, daar zit klaarblijkelijk meer verschil tussen. Hoe groot dat verschil is, daar blijf jij maar steeds op te hameren. Die indruk krijg ik tenminste.

[Jan Onderwater]

Je snapt het punt niet, het gaat niet om computers of servers, het gaat om electronische apparaten waarvan de meeste mensen geen idee hebben dat er een OS (vaak linux versie) in zit. Van cameras tot afstandbedieningen, vaatwassers, modems, routers, koelkasten, digitale radios etc etc etc.
Deze apparaten zullen zich zelf moeten voorzien van updates, en als dat niet het geval is, omdat de fabrikant ze niet meer ondersteund of er niet meer is, is dat een mogelijk Security issue als deze aan het huis netwerk hangen of een open WiFi hebben.

[Mellow Jack]

Bovenstaande geeft aan dat het veel minder moeite kost om een Linux systeem up-to-date te krijgen en/of te houden dan Windows servers. In mijn omgeving draaien er Windows werkstations, Windows servers, Linux servers, Linux werkstations en een "verdwalde" FreeBSD server. Drie keer raden welke servers/werkstations significant meer tijd aan onderhoud vergen. Tip: gok niet op Linux of FreeBSD.

Dat is niet echt de waarheid. In een professionele omgeving zijn zowel Linux en Windows. Het OS. Met 1 druk op de knop of 1 commando massaal te updaten zonder issues. Vaak is het zelfs een schedule.

Het nadeel voor Windows is dat deze druk op de knop vaak niet voor applicaties gedurft worden.

Het nadeel voor Linux is dan weer dat je moet hopen dat je distro de juiste patches heeft gebackport naar de software en dat die backports veelal niet worden gezien als eventuele oplossing door vurnability scanners.

Hoewel Linux mijn voorkeur heeft voor applicatie stacks vind ik persoonlijk dat je toch wel veel tijd kwijt bent om te bewijzen dat hoewel je Tomcat/Apache/Nginx een oudere versie heeft hij wel de juiste security patches heeft ontvangen om isseu X te mitigeren

Note: voor desktops gaat hetzelfde principe op alleen hebben die tegenwoordig het issue dat ze niet altijd connected zijn (bijv. Laptops) waardoor het wel 1 druk op de knop is maar je lastig de garantie kan geven dat de updates binnen een dag zijn doorgevoerd. Mja dat is desktop eigen en zou je ook op Linux hebben

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 12:25]

[lenwar]

Het gaat er natuurlijk om dat de patches wel snel beschikbaar zijn.

Dit is wat mij betreft een misvatting. Als een patch beschikbaar is en niet wordt gebruikt heb je nog steeds een probleem. Dan kan je stellen 'dat doe je jezelf (en je medemens) aan', maar de onveilige situatie blijft zolang deze misbruikt kan worden.
Een beveiligsfout die niet misbruikt wordt kan objectief gezien geen kwaad. (puur theoretisch/utopisch natuurlijk)

(( Simpel voorbeeld: Google patched de Android kernel, maar telefoonfabrikant xyz patched het toestel niet meer, of pas over 6 maanden. De patch is er, maar effect blijft het lek bestaan. Daar kan Google niks aan doen, en de gebruiker ook niet in dit voorbeeld. Android 'is weer veiliger', maar alleen theoretisch. ))

Ieder besturingssyteem kan veilig of onveilig zijn of gebruikt worden. Of Linux veiliger is dan MacOS, Windows, FreeBSD, Z/OS, enz. enz. enz. is denk ik heel moeilijk om te bepalen. Al is het maar omdat het heel moeilijk is om het meetbaar/toetsbaar te maken.

Als je bijvoorbeeld zou meten op het aantal CVEs:
https://www.cvedetails.com/top-50-products.php

Dan is het Windows 10 veiliger dan MacOS X (waarschijnlijk omdat MacOS X lang bestaat dan Windows 10). (( als je per jaar kijkt zie je ze trouwens aardig op en neer schuiven ))

Maar puur daar op meten zou vreemd zijn. Stel dat er 10.000 CVEs komen voor een product dat maar op 100 computers staat die niet met het internet verbonden zijn en voor de toegang moet je door drie kluisdeuren heen nadat je door 30 mensen bent gescreend en geïnterviewed. Dan is dat systeem zo lek als een mandje, maar is dat waarschijnlijk in de praktijk niet zo heel spannend.

Je zou ook een soort afweging kunnen maken met 'hoe veel heel ernstige CVEs' er zijn. Maar wat is erger. 1 met een score van 9, of 5 met een score van 8. Is wat mij betreft moeilijk te bepalen. Bij onderstaande tabel hebben ze in elk geval hun mening hier over:
https://www.cvedetails.co...vssscore-distribution.php

[Soldaatje]

Van android dat is een goed punt, vraag me af of gebruikers met deze bug ook makkelijker kunnen rooten?

[Reactie gewijzigd door Soldaatje op 23 juli 2024 12:25]

[Chielllie]

Heel off topic, maar dat vind ik ook raar. En vanmorgen kon ik een plus artikel nog lezen over Layar en dat is nu ook weg.
Ik vroeg me af of dat met het ingaan van de nieuwe abonnementen te maken had. De mijne was net verlengd dus ik ging er vanuit dat ik nog een jaartje Plus kon blijven lezen.

[MN-Power]

Ik vind het heerlijk om de plus artikelen niet te zien. Niets zo irritant als even de tag missen, op het artikel klikken waarvan je nog net de inleiding weet te lezen(bijvoorbeeld motorsports.com met hun prime artikelen) en geïrriteerd weer op de back knop drukken.

[Cergorach]

En vanmorgen kon ik een plus artikel nog lezen over Layar en dat is nu ook weg.

reviews: Hoe Nederlandse start-up bijna techgigant werd

[TTommie]

Goede vraag vroeg het mij ook af.

Denk dat ze niet overweg konden met de meestal negatieve reacties die erop kwamen.

[rbr320]

Ik heb geen Tweakers abo en kan ze nog gewoon zien:

plan: Tweakers introduceert op 22 juli nieuwe abonnementen
reviews: Hoe Nederlandse start-up bijna techgigant werd

En van zojuist:
plan: Nieuwe Tweakers-abonnementen zijn beschikbaar