Ontwikkelaars verhelpen oude Linux-kwetsbaarheid die rechten kan verhogen

Er is een exploit verschenen voor een negen jaar oude kwetsbaarheid in Linux, die kwaadwillenden de mogelijkheid geeft hun lokale rechten te verhogen. Ontwikkelaars hebben een kernel-fix uitgebracht om de zogenoemde Dirty COW-kwetsbaarheid te dichten.

Dirty COW is een zogenoemde privilege-escalationkwetsbaarheid. De oorzaak ligt bij de manier waarop het geheugensubsysteem van de Linux-kernel copy-on-write bij private read-only-mappings afhandelt. Hierdoor kan een gebruiker schrijfrechten verkrijgen bij wat eigenlijk read-only moet zijn en zo zijn beheerdersrechten verhogen.

De bug zit al sinds 2007 ofwel vanaf versie 2.6.22 in Linux, maar krijgt nu pas aandacht. De ontdekker, Phil Oester van Red Hat, heeft namelijk geconstateerd dat er een exploit voor is uitgebracht en de kwetsbaarheid dus 'in het wild' wordt misbruikt. Tegenover Ars Technica laat Oester weten dat 'elke gebruiker in minder dan vijf seconden root kan krijgen'. De site schrijft dat exploits bijvoorbeeld ingezet kunnen worden via hostingbedrijven die shelltoegang bieden of als onderdeel van een andere aanval die toegang geeft tot een systeem met beperkte rechten, om vervolgens roottoegang te verkrijgen.

De kwetsbaarheid heeft de aanduiding CVE-2016-5195 en een eigen pagina met meer details over de impact gekregen. De ondersteunde Linux-kernelseries 4.8, 4.7 en 4.4 hebben een nieuwe release gekregen om het probleem aan te pakken. Ook Red Hat, Debian en Ubuntu hebben fixes uitgebracht. De ontwikkelaars van de distro's hebben de kwetsbaarheid als 'belangrijk' gekwalificeerd.

Reacties (81)

Houdt dit nu in dat alle Android-telefoons hier op dit moment nog gevoelig voor zijn?
En betekent dat dan ook dat iedere app die gegevens uit het OS leest die in principe ook kan wijzigen? Of begrijp ik dat verkeerd?

Dat begrijp je verkeerd.
De kans is inderdaad erg groot dat Android telefoons hier ook gevoelig voor zijn, ze draaien immers een Linux kernel. Alle Android versies vanaf kernelversie 2.6.22 zijn hier dus zeer waarschijnlijk gevoelig voor.

Nee, niet iedere app die gegevens uit het OS kan lezen kan deze ook wijzigen. Er zullen maar weinig apps gebruik maken van copy-on-write. Daarnaast moet de app dan ook nog eens op de juiste (of eigenlijk verkeerde) wijze gebruik maken van copy-on-write om schrijfrechten te verkrijgen.

Helaas is er nog steeds geen goed upgrade beleid voor Android telefoons, dus deze lek schrijven we op bij de rest van het lijstje.

_{De -1's komen natuurlijk vanwege mijn opmerking over het falende update/upgrade beleid van Android devices}

[Reactie gewijzigd door walteij op 21 oktober 2016 14:28]

Wat wel zo is is dat Android apps (inclusief de apps die met de NDK ipv de SDK geschreven zijn) elk in hun eigen sandbox draaien die wat de app kan doen nogal beperkt, dus het kan in principe dat die apps de vulnerability niet zomaar kunnen exploiten. Maar dat is niet te zeggen zonder alle details over de sandbox en de dirty cow vulnerability bij elkaar te schrapen en dan te kijken of de sandbox roet/root in het eten gooit.

Ben je zeker dat deze copy-on-write techniek niet iets is wat Linux altijd doet - onderdeel van het memory management systeem - en waar je als gebruiker/programmeur absoluut geen controle over hebt. Ik denk dat deze memory "deduplication" techniek bijna altijd draait.

Dit is dus alleen te misbruiken als de gebruiker toegang heeft met ssh shell op de bak (ssh, php of dergelijke).

Als je kernel versie gelijk of hoger is als: "Linux 3.13.0-100-generic" dan zit je goed. Je kan dit bekijken door "uname -a" ui te voeren

Om de laatste kernel release binnen te halen moet je eerst je Server / Desktop opnieuw opstart!
en daarna:

Ubuntu Fix (eerst herstarten):
sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo reboot

CentOS en RHEL Fix (eerst herstarten):
sudo yum update -Y && sudo reboot

Ubuntu is ook live te patchen zonder reboot:
http://www.cyberciti.biz/...kernel-without-rebooting/

Voor CentOS en RHEL kan je via de volgende methode kijken of je vatbaar bent.
wget https://access.redhat.com...les/rh-cve-2016-5195_1.sh
bash rh-cve-2016-5195_1.sh

bronnen:
http://www.securityweek.c...el-flaw-exploit-seen-wild
https://auth.livepatch.canonical.com/
http://www.cyberciti.biz/...lation-vulnerability-fix/

[Reactie gewijzigd door xleeuwx op 21 oktober 2016 15:11]

Ubuntu Fix (eerst herstarten):
sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo reboot

Overdrijf je niet een beetje? Als je automatische updates om wat voor reden dan ook hebt uitgeschakeld (anders hoef je namelijk NIETS te doen), dan is update+upgrade toch al genoeg? Met dist-upgrade kan je je systeem behoorlijk om zeep helpen, zoals snaf aangeeft.

En van tevoren herstarten is nergens voor nodig.

In hoeverrehelpt dist-upgrade je systeem om zeep?

[...]


Overdrijf je niet een beetje? Als je automatische updates om wat voor reden dan ook hebt uitgeschakeld (anders hoef je namelijk NIETS te doen), dan is update+upgrade toch al genoeg? Met dist-upgrade kan je je systeem behoorlijk om zeep helpen, zoals snaf aangeeft.

En van tevoren herstarten is nergens voor nodig.

Heb je ervaring met dist-upgrade?

Als je aan je systeem de juiste repo's toegevoegd hebt help je met een dist-upgrade een systeem niet om zeep.
Als je niet weet wat je doet en repos van verschilende distro release versies gaat mixen gaat het fout.
Dat niet iets dat je dist-upgrade kunt verwijten.
Ik heb nog nooit problemen gehad met dist-upgrade op Debian. En ook nooit met een zypper dup op openSUSE.

[Reactie gewijzigd door Anoniem: 112442 op 23 oktober 2016 02:59]

Waarom zou het dan als webserver user niet mogelijk zijn? Zolang je je binary maar op de server krijgt en deze als een user kunt uitvoeren, dan ben je toch binnen? BIjvoorbeeld door een PHP script te kunnen plaatsen die de binary download en vervolgens execute.

Daarnaast: bugfixes kunnen prima gebackport worden. Je hoeft dus helemaal niet de meest recente upstream versie te hebben om toch veilig te zijn.

De bugfixes zijn er echter nog niet voor alle releases, daarnaast is het nu het snelste om je kernel bij te werken, bij Ubuntu (staat er ook bij) kan je de server gewoon live patchen.

heb de reactie klein beetje aangepast.

[Reactie gewijzigd door xleeuwx op 21 oktober 2016 15:11]

sudo apt-get dist-upgrade -y

Ubuntu is ook live te patchen zonder reboot:
http://www.cyberciti.biz/...kernel-without-rebooting/

Zeg er dan wel meteen bij dat dist-upgrade niet bevorderlijk is voor de stabiliteit van je systeem.
En de (gratis) Ubuntu live patch alleen op kernel 4.4 werkt

[Reactie gewijzigd door Anoniem: 719316 op 21 oktober 2016 15:42]

[...]

Zeg er dan wel meteen bij dat dist-upgrade niet bevorderlijk is voor de stabiliteit van je systeem.
En de (gratis) Ubuntu live patch alleen op kernel 4.4 werkt

Kun je het dist-upgrade verhaal a.u.b. onderbouwen. Mijn ervaring is namelijk heel anders. Nooit problemen gehad bij een goed geconfigureerd systeem. Altijd dist-upgrade gebruikt op Debian.

[Reactie gewijzigd door Anoniem: 112442 op 23 oktober 2016 09:55]

Debian based systems can also be upgraded by using apt dist-upgrade. However, using do-release-upgrade is recommended because it has the ability to handle system configuration changes sometimes needed between releases.

Uit: https://help.ubuntu.com/l...installing-upgrading.html

In feite is een dist-upgrade een tussentijdse ongecontroleerde upgrade. Als een nieuwe release-upgrade uitkomt dan wordt o.a. de stabiliteit van de afhankelijkheden van de onderlingen pakketten getest. Dat is ook de reden dat je niet tussentijds bv zomaar de nieuwste GNOME versie kan installeren zonder dit ten koste van de stabiliteit te laten gaan. Vandaar ook dat sommigen zo blij zijn met dat hele Flatpak/Snappy gedoe want daarmee heb je geen onderlinge afhankelijkheden meer
Als je toch stabiel maar wel zsm het nieuwste wilt raad ik je openSUSE Tumbleweed aan. Die heeft vrij snel de nieuwste kernels en GNOME desktop enz.

[Reactie gewijzigd door Anoniem: 719316 op 23 oktober 2016 10:25]

[...]

Uit: https://help.ubuntu.com/l...installing-upgrading.html

Dat is typisch iets van Ubuntu. Deze optie bestaat bij Debian niet.

Ik zie nergens staan dat een dist-upgrade, binnen een release versie, je systeem stuk kan maken. Want daar gaat het over.

In feite is een dist-upgrade een tussentijdse ongecontroleerde upgrade. Als een nieuwe release-upgrade uitkomt dan wordt o.a. de stabiliteit van de afhankelijkheden van de onderlingen pakketten getest. Dat is ook de reden dat je niet tussentijds bv zomaar de nieuwste GNOME versie kan installeren zonder dit ten koste van de stabiliteit te laten gaan

Zie de verschillen.

upgrade
upgrade is used to install the newest versions of all packages
currently installed on the system from the sources enumerated in
/etc/apt/sources.list. Packages currently installed with new
versions available are retrieved and upgraded; under no
circumstances are currently installed packages removed, or packages
not already installed retrieved and installed. New versions of
currently installed packages that cannot be upgraded without
changing the install status of another package will be left at
their current version. An update must be performed first so that
apt-get knows that new versions of packages are available.

dist-upgrade
dist-upgrade in addition to performing the function of upgrade,
also intelligently handles changing dependencies with new versions
of packages; apt-get has a "smart" conflict resolution system, and
it will attempt to upgrade the most important packages at the
expense of less important ones if necessary. So, dist-upgrade
command may remove some packages. The /etc/apt/sources.list file
contains a list of locations from which to retrieve desired package
files. See also apt_preferences(5) for a mechanism for overriding
the general settings for individual packages.

Alleen bij broddelwerk zal dist-upgrade problemen geven. Upgrade kijkt niet naar de kwaliteit van paket. Als het niet werkt maar wel officieel aangeboden wordt zal upgrade het gewoon installeren.
Ik heb jaren Debian squeeze/wheezy/Jessie in combinative met testing gebruikt. Dist-upgrade heeft nooit problemen gegeven alleen foutjes in testing die even enkele keer even problem waren. Maar dat ligt niet aan dist-upgrade.

Als je toch stabiel maar wel zsm het nieuwste wilt raad ik je openSUSE Tumbleweed aan. Die heeft vrij snel de nieuwste kernels en GNOME desktop enz.

Ik gebruik bij voorkeur al sinds 1996 SuSE(oude naam)/openSUSE. Eerst de normale distro daarna Factory en sinds Tumbleweed de Factory vervanger voor de gebruikers is Tumbleweed.

[Reactie gewijzigd door Anoniem: 112442 op 23 oktober 2016 11:05]

Sorry, had wat verdere uitleg bijgevoegd in mijn vorige reaktie
Ik snap niet wat je bedoeld met deze optie bestaat niet in Debian. Volgens mij bestaan zij allebei in beide distro's.

Sorry, had wat verdere uitleg bijgevoegd in mijn vorige reaktie
Ik snap niet wat je bedoeld met deze optie bestaat niet in Debian. Volgens mij bestaan zij allebei in beide distro's.

Ik ben nu op mijn smartphone aan het klooien, daarom kan ik niet direct op een systeem kijken.
Maar uit mijn geheugen en google.
What is Debian's equivalent of do-release-upgrade to upgrade the operating system?

Volgens mij heb je helemaal gelijk, er is in Debian geen do-release-upgrade
Het Debian geadviseerde is idd apt-get dist-upgrade voor upgrade tussen releases (en aptitude full-upgrade binnen release).
Dist-upgrade wordt bij Ubuntu ontraden
Aangezien Debian als rock-solid kan worden beschouwd moet ik aannemen dat dit specifiek Ubuntu is en zij hiervoor do-release-upgrade in het leven hebben geroepen.

[Reactie gewijzigd door Anoniem: 719316 op 23 oktober 2016 11:17]

De patch die RedHat heeft uitgebracht is nog niet via een update binnen te halen.

Ik heb zojuist mn CentOS 7 installatie geupdate en ben nogsteens vulnerable

Om de laatste kernel release binnen te halen moet je eerst je Server / Desktop opnieuw opstart!

Wat is je motivatie om de server eerst opnieuw op te starten, ik neem aan reboten?

Deze opmerking omdat je update ook direct kan installeren. En als de exploit al gebruikt is heb je geen betrouwbaar systeem meer, dit zul je opnieuw moeten opzetten.

Fraai staaltje samenwerking. Iemand ontdekt een probleem, ziet dat het ernstig is, meldt het, en het wordt gefikst. Goed werk van betrokken partijen.
Toch geeft het kippenvel dat we allemaal al bijna 10 jaar hiermee hebben gewerkt :-S

@tweakimv hieronder,
een groter probleem - wat bedoel je daarmee?

[Reactie gewijzigd door increddibelly op 21 oktober 2016 14:52]

Degene die het ontdekte is niet zomaar iemand, maar een medewerker van RedHat, een van de grootste Linux distributeurs die er bestaat (CentOS is RedHat voor mensen die er niet voor willen betalen). RedHat zal zelf ongetwijfeld direct hebben geholpen bij het verhelpen van het lek.

RedHat heeft het ontdekt en een kernel ontwikkelaar heeft een fix die negen jaar geleden niet geimplementeerd kon worden nu geimplementeerd.

De oplossing was er al echter werd tegen gehouden door een groter probleem. Men is het denk ik gewoon een beetje vergeten en nu heeft iemand het ontdekt en kan het wel gefixed worden.

RedHat heeft het ontdekt en een kernel ontwikkelaar heeft een fix die negen jaar geleden niet geimplementeerd kon worden nu geimplementeerd.

En volgens de gelinkte artikels heeft Linus het zelf ook proberen fixen 11 jaar geleden. Maar heeft hij wat later de commit moeten reverten wegens problemen op de s390 architectuur.

10 jaar lijkt veel, genoeg bug die nu pas ontdekt worden en in de toekomst ontdekt gaan worden die misschien nog ouder kunnen zijn.

Soms loop je door een toeval tegen dit soort bugs aan en komt het boven water.

Alleen was deze bug al 10 jaar bekend...

Alleen was deze bug al 10 jaar bekend...

Ik zou de artikels eens lezen en een keer het CVE systeem leren kennen. CVE-2016-5195 2016 een bug die in 2016 ingelegd is.

Het is niet uniek dat bugs pas na lange tijd ontdekt worden. Zo zijn er bij Microsoft ook bugs gevonden die al vele jaren in hun OS zaten.

Wat Phil Oester aangeeft is dat de bug al langer bekend was in de criminele wereld. En misbruikt is, de criminele wereld deelt helaas nooit iets, zoals verwacht kan worden.

[Reactie gewijzigd door Anoniem: 112442 op 22 oktober 2016 09:56]

Bedankt voor de toelichting over het systeem, Maar waarom moeten moeten mensen bronnen lezen en leren om neit door jou uitgekaffert te hoeven worden? Je mag er vanuit gaan dat de informatie in het artikel correct is, en het artikel suggereert wel degelijk tot drie keer toe dat het om een oud en bekend lek gaat:

Ontwikkelaars verhelpen oude Linux-kwetsbaarheid
...
Er is een exploit verschenen voor een negen jaar oude kwetsbaarheid in Linux
...
De bug zit al sinds 2007 ofwel vanaf versie 2.6.22 in Linux, maar krijgt nu pas aandacht. De ontdekker, Phil Oester van Red Hat, heeft namelijk geconstateerd dat er een exploit voor is uitgebracht en de kwetsbaarheid dus 'in het wild' wordt misbruikt.

De door Tweakers gesuggereerde reden voor het aanpakken van de bug is dus dat er een exploit voor in het wild is uitgebracht, niet dat het nu pas ontdekt zou zijn. Mocht dat niet kloppen dan moet je bij Tweakers zijn, niet commentors erop aanvallen dat ze het niet telepathisch 'goed' vertalen tijdens het lezen.

Het doet overigens weinig af aan de essentiele kritiek dat er 9 jaar een bug in Linux gezeten heeft. En dat terwijl Linux/FOSS propagandisten vaak verkondigen dat dat in Linux niet voor kan komen omdat er zoveel mensen naar de code kunnen kijken. Echter nu heeft er in 9 jaar of niemand naar de code gekeken, of niemand het gezien heeft of niemand de moeite heeft genomen het te fixen.
Ook is dit het zoveelste soortgelijke issue de afgelopen jaren.

Wat niet per se betekend dat de filosofie niet klopt, maar wel dat theorie en praktijk niet overeenkomen, En dat het iets is om in de overweging mee te nemen als je (professioneel) op Linux overgaat,

Volgens mij kaffer ik niemand uit. I suggereert dat hij zich beter in de informatie moet verdiepen.

Ik heb gevoel dat je mijn terechtwijzing als stotender ziet dan onwaarheden verkondigen?

Jij bent degene die onwaarheden verkondigt. Misschien moet je je wat beter in de informatie verdiepen.

[...]


Jij bent degene die onwaarheden verkondigt. Misschien moet je je wat beter in de informatie verdiepen.

In de opmerking van de CVE zit helemaal geen onwaarheid. Zodra een onveiligheid in Software gevonden wordt, wordt er een CVE gemaakt.
Of probeer he te beweren dat Linus en de andere ontwikkelaars deze veiligheidsbug onder pet hebben proberen te houden. Zo ja, dan zou ik hier graag bewijs van zien.


Aan de hand van de link die je gepost hebt.

Inderdaad, 9 jaar klopt niet. Het was 11 jaar.

Ze hebben het over kernel 2.6.22 = linux-2.6.22.tar.bz2 08-Jul-2007 23:48 43M . Zoals je ziet 8 juli 2007 uitgekomen.

Waarom heb je niet naar de betreffende commits gezocht, vooral waar de commit teruggedraaid werd?

De commit die later terug gedraaid werd.

De terug draai commit.

De discussie t.a.v. het terug draaien.

Daar werd gezegd dat dit probleem in de code afgevangen werd. Waarschijnlijk is er in Kernel 2.6.22 iets veranderd waardoor dit probleem niet meer afgevangen werd.

Kortom probleem niet bekend als beveiligingsprobleem tot de CVE.

Dit is IMO het mooie van opensource je kunt in de keuken meekijken ook als een keer iets aanbrand. Zoiets zul je niet zien bij closed sorce.

[Reactie gewijzigd door Anoniem: 112442 op 22 oktober 2016 21:37]

[...]


In de opmerking van de CVE zit helemaal geen onwaarheid. Zodra een onveiligheid in Software gevonden wordt, wordt er een CVE gemaakt.
Of probeer he te beweren dat Linus en de andere ontwikkelaars deze veiligheidsbug onder pet hebben proberen te houden. Zo ja, dan zou ik hier graag bewijs van zien.


Aan de hand van de link die je gepost hebt.


[...]


Ze hebben het over kernel 2.6.22 = linux-2.6.22.tar.bz2 08-Jul-2007 23:48 43M . Zoals je ziet 8 juli 2007 uitgekomen.

Waarom heb je niet naar de betreffende commits gezocht, vooral waar de commit teruggedraaid werd?

De commit die later terug gedraaid werd.

De terug draai commit.

De discussie t.a.v. het terug draaien.

Dat is toch allemaal 2005? Dus waar baseer je je aanname op dat ik die commits niet heb opgezocht?

Daar werd gezegd dat dit probleem in de code afgevangen werd. Waarschijnlijk is er in Kernel 2.6.22 iets veranderd waardoor dit probleem niet meer afgevangen werd.

"Daar" is een discussie van 63 mails. Misschien kan je iets specifieker zijn, want ik ga ze niet allemaal lezen als Linus Torvalds zelf zegt dat het een 11 jaar oude bug is die nu makkelijker kan worden gefixt omdat het s390-probleem is verholpen.

[...]

Dat is toch allemaal 2005? Dus waar baseer je je aanname op dat ik die commits niet heb opgezocht?

Omdat je alleen link die in het artikel staat poste.

[...]

"Daar" is een discussie van 63 mails. Misschien kan je iets specifieker zijn, want ik ga ze niet allemaal lezen als Linus Torvalds zelf zegt dat het een 11 jaar oude bug is die nu makkelijker kan worden gefixt omdat het s390-probleem is verholpen.

Dit is de mail met een alternatieve patch.

Vanaf die tijd was de bug van de radar want het probleem was opgelost.

[Reactie gewijzigd door Anoniem: 112442 op 23 oktober 2016 10:18]

Dat ging puur over het gebruik van -1 voor VM_FAULT_OOM. In de reacties op die mail (1 2)kan je lezen dat die patch van Linus NIET de oplossing was.

Dat ging puur over het gebruik van -1 voor VM_FAULT_OOM. In de reacties op die mail (1 2)kan je lezen dat die patch van Linus NIET de oplossing was.

Dat klopt en daarom is er een alternatieve patch gebruikt. Zie mijn link uit het vorige reactie.

Daar reageer ik juist op. Dat ging puur over het gebruik van -1 voor VM_FAULT_OOM. In de reacties op die mail (1 2)kan je lezen dat die patch van Linus NIET de oplossing was.

En wat staat hier over de leeftijd, en hoe lang de bug al bekend is?

En wat staat hier over de leeftijd, en hoe lang de bug al bekend is?

Het is als veiligheids-bug sinds 20160531 bekend, zie CVE-2016-5195.
Van te voren was het een normale bug. Niet iedere bug is een beveiligingsprobleem.

Kijk ook even naar mijn andere reactie, op je vorige reactie, waar je me beschuldigd van onwaarheden.

En wat zei xFeverr? "Alleen was deze bug al 10 jaar bekend..." Ik snap dat je je uit deze discussie probeert te lullen, maar ook met het veranderen van de voorwaarden ("we hebben het over de veilighedsbug, niet de gewone bug") gaat je dat niet lukken. Ik zie namelijk geen "veiligheid" in zijn tekst. Jij wel?

En wat zei xFeverr? "Alleen was deze bug al 10 jaar bekend..." Ik snap dat je je uit deze discussie probeert te lullen, maar ook met het veranderen van de voorwaarden ("we hebben het over de veilighedsbug, niet de gewone bug") gaat je dat niet lukken. Ik zie namelijk geen "veiligheid" in zijn tekst. Jij wel?

“Most serious” Linux privilege-escalation bug ever is under active exploit (updated)

Hij reageerde op @bbob1970.
Die had het weldegelijk over de ontdekking = toen het een cve werd.

It says Oester found the exploit using an HTTP packet capture, but the site doesn't elaborate.

Dat maak jij ervan. bbob1970 heeft het over bugs in het algemeen, niet eens over deze specifieke bug, laat staan over een bepaald aspect ervan.

Als dit MS of Apple was geweest stonden de Linux fanboys te brullen hoe schandalig het is dat een fix zo lang op zich laat wachten, en dat bij open-source een bug meteen gefixt wordt... Nu is het erg stil...

Desalniettemin goed dat de bug gefixt is

Als implecerd dat de fix 9 jaar op zich heeft latem wachten, dan klopt dat helemaal niet.
De ontdekking en creatie van CVE-2016-5195 was op 20160531 dat is niet de 9 jaar waar jij het over hebt.

Inderdaad, 9 jaar klopt niet. Het was 11 jaar.

Inderdaad, 9 jaar klopt niet. Het was 11 jaar.

Kijk even naar mijn reactie waar je me beschuldigd van onwaarheden dan zie je ook waar de 9 i.p.v. 11 jaar vandaan komt.

Wie dan? Elke software.. opensource closed source zit vol met bugs. Niemand in de hele wereld kan weten hoeveel bugs in welke software ook zitten of zeggen dat in de ene OS meer bugs zitten als de andere.

Daarnaast maakt het toch niet uit. De NSA heeft een magazijn vol staan met zero day exploits voor welk OS dan ook. Ze trekken er zo even wat uit de kast. Zie Stuxnet waar gewoon 4 zero day exploits in zaten verwerkt. Dat is ongekend. Ik mag hopen dat je ook de documentaire gezien hebt? Het ging daarom ook om zero days voor Windows als OS. En Siemens Scada pakket en PLC's e.d.

[Reactie gewijzigd door Texamicz op 22 oktober 2016 16:37]

Dat verhaal houdt pas op bij de eindgebruiker die de patch ook nog even moet indraaien, anders heeft het allemaal geen zin

Dat gaat bij alle distro's die ik ken vrijwel vanzelf. Eindgebruikers hoeven tegenwoordig hooguit nog aan te klikken dat ze de beschikbare update inderdaad willen installeren, vergelijkbaar met Windows updates.

Fraai staaltje samenwerking. Iemand ontdekt een probleem, ziet dat het ernstig is, meldt het, en het wordt gefikst. Goed werk van betrokken partijen.

Je bent ergens vergeten "7 jaar wachten" te schrijven. Als je dit al een fraai staaltje werk noemt...

Je imho makkelijke opmerking suggereert dat het prutswerk is dat er 7 jaar lang een bug in een mag kernel zitten. Nou, mijn beste, er zijn maar heel weinig organisaties op de wereld waar de capaciteit bestaat om bugloze software op te leveren, ondanks dat het mensenwerk is. En Red Hat is daar niet één van.

En áls er dan iets gevonden wordt, dan wil je toch dat er op deze manier mee wordt omgegaan. Yep, een fraai staaltje samenwerking.

Waar het om gaat is dat er 7 (of 9) jaar lang een ernstige maar _bekende_ bug in heeft gezeten.

Microsoft zou er zeker weten om afgefakkeld worden maar bij Linux gaat het om 'een fraai staaltje samenwerking'

Het is niet omdat de bug er 7 jaar ingezeten heeft, dat het ook al 7 jaar *bekend* is dat hij erin zat.

Voor hetzelfde geld hebben ze dat pas dit ajar geconstateerd, en dan gaan terugkijken hoelang hij al in de code zit.

@Glashelder heeft, waarschijnlijk zonder het te weten, ergens wel een puntje. Ik las ergens dat deze bug kort na zijn introductie al door Linus Torvalds zelf verholpen was. Deze patch is toen echter om onduidelijke redenen ongedaan gemaakt en daarna is er niemand geweest die het alsnog gefikst heeft. Dat is niet bepaald wat ik versta onder goed werk afleveren.

Te lezen in het commit bericht is dat de bug bij Linus Torvalds al zo'n 11 jaar bekend is. Het is ooit geprobeerd te fixen, maar deze fix was niet goed geimplementeerd en werd teruggedraaid. Daarna is het waarschijnlijk vergeten, vandaar dat het nu pas weer naar boven komt.

Als het 11 jaar geleden openbare kennis was dat deze bug (toen haast niet uitvoerbaar) in de kernel zat, lijkt het me sterk dat er niemand aan gedacht heeft in de afgelopen 7~9~11 jaar.

Het is goed dat het nu gefixt is, maar het is vrij slordig dat een mislukte fix van zo'n groot probleem zomaar vergeten is.

Alleen was de fout wel degelijk al tijd, zelfs jaren, bekend maar is er pas opgetreden toen men zag dat er al exploits voor waren. Zoals Glashelder al zegt: andere, en vooral Microsoft, zouden de wind van voren hebben gekregen mocht het blijken dat een bekende ernstige bug 7 jaar lang in het OS heeft gezeten. Zelfs als die niet bekend zou zijn geweest. Belachelijk om dan nu Linux hier de hemel in te gaan prijzen voor 'een fraai staaltje werk'.

Dat hier fouten gemaakt zijn staat buiten kijf, maar doen alsof de bug bewust niet is gepatcht en er is gewacht tot er actief misbruik van gemaakt werd is niet correct. Het euvel was bekend en er was zelfs al een fix voor, die is echter door omstandigheden nooit in de kernel toegepast.

Die "fix" gaf problemen op een bepaalde architectuur en is teruggedraaid. Die had natuurlijk daarna weer als "bug" op de lijst gezet moeten worden. Gewoon jammer eigenlijk.

Microsoft maakt natuurlijk nooit zulke fouten... Bugs van resp. 15 en 19 jaar oud! Prutsers!

Persoonlijk heb ik er niet echt een smaak naar dat een ernstig lek gevonden wordt en er pas opgetreden wordt als er een exploit voor is jaren later. Dat is alles behalve een "fraai staaltje samenwerking", zo hoor je niet om te gaan met een bekend probleem.

Aan de andere kant zit er misschien wel iemand bij de NSA die denkt, "shit, ze hebben het eindelijk gevonden"

Alleen zie ik nog steeds geen fix bij de updates

Ik heb 'm gisterochtend al gehad. Welke distro gebruik je?

Het ergste is dat daardoor (doordat de kwetsbaarheid er zo lang in zat) heel veel apparaten met een op Linux gebaseerd OS, helemaal niet gefixt zullen worden omdat ze geen support meer krijgen.

Probeer al een paar keer nu om de reference exploit (https://github.com/dirtyc...io/blob/master/dirtyc0w.c) toe te passen op mijn Ubuntu 16.04 installatie, maar nog zonder succes. De inhoud van het bestand 'foo' blijft netjes 'this is not a test'. Er staat expliciet dat Red Hat EL 5 en 6 niet kwetsbaar zijn, maar het is in ieder geval ook niet doodeenvoudig om het op Ubuntu voor elkaar te krijgen.

Aangezien het om een race condition lijkt te gaan is het natuurlijk best mogelijk dat ik gewoon 'geluk' heb gehad met mijn tests.

[update]Oh, ik heb de geptachte versie van de kernel, 4.4.0-45.66, al. Vreemd, want ik heb de afgelopen dagen geen updates geinstalleerd, terwijl de gepatchte kernel-package 19 oktober, afgelopen woensdag dus, gereleased is Sowieso is het nieuws dus wat aan de late kant.[/update]

De merchandise is wel briljant trouwens. Leuke prijskaartjes

[Reactie gewijzigd door MadEgg op 21 oktober 2016 14:38]

Als je het package unattended-upgrades geïnstalleerd hebt (en dat is standaard het geval op Ubuntu) worden in de standaard configuratie security updates dagelijks op de achtergrond uitgevoerd. Dit gedrag kan je eventueel wijzigen in de file /etc/apt/apt.conf.d/50unattended-upgrades

Als je het package unattended-upgrades geïnstalleerd hebt (en dat is standaard het geval op Ubuntu) worden in de standaard configuratie security updates dagelijks op de achtergrond uitgevoerd. Dit gedrag kan je eventueel wijzigen in de file /etc/apt/apt.conf.d/50unattended-upgrades

Als hij de kernel live patch niet gebruikt zal hij het systeem moeten reboten om de nieuwe kernel te "activen".

Klopt, maar als je iedere avond netjes je pc afsluit zal Ubuntu bij de volgende boot automatisch de nieuwste kernel starten, in dit geval dus degene met de patch.

Klopt, maar als je iedere avond netjes je pc afsluit zal Ubuntu bij de volgende boot automatisch de nieuwste kernel starten, in dit geval dus degene met de patch.

Je hebt het puur en alleen over een desktop. Linux wordt ook heel vaak als server ingezet die altijd aan staat.

Je hebt het puur en alleen over een desktop. Linux wordt ook heel vaak als server ingezet die altijd aan staat.

Ik zou zelfs durven beweren dat Linux vaker wordt gebruikt op servers dan op de desktop, maar dat is in dit geval niet relevant.

@MadEgg heeft het in zijn post met geen woord over op wat voor machine hij in dit geval Ubuntu draait. We kunnen er dus slechts over speculeren. Echter het feit dat hij de gepatchte kernel al wel gebruikte zonder het te weten geeft naar mijn idee aan dat zijn testmachine wel degelijk geupdate en gereboot was. Ik gaf slechts informatie die duidelijkheid zou kunnen verschaffen over hoe de gepatchte kernel ongemerkt op het systeem terecht gekomen zou kunnen zijn.

[Reactie gewijzigd door rbr320 op 24 oktober 2016 13:00]

De merchandise is wel briljant trouwens. Leuke prijskaartjes

Hehehe, ja kernel dev's moeten ook eten

Wat voor gevolgen heeft dit voor Android? Als je hier geen patch voor krijgt op je telefoon, kunnen dan alle apps zomaar rootrechten krijgen?

Android maakt gebruik van de linuxkernel. Aangezien het probleem in de kernel zit zal het bij android niet ineens niet aanwezig zijn.
Dit artikel stelt android ook kwetsbaar.

Android maakt gebruik van de linuxkernel. Aangezien het probleem in de kernel zit zal het bij android niet ineens niet aanwezig zijn.
Dit artikel stelt android ook kwetsbaar.

Natuurlijk is het ook kwetsbaar als je gecompileerde code gebruikt. Ik pleit niet tegen gecompileerde code op Android dat is mijn voorkeur.

Dit lek heeft op Android een heel groot voordeel voor sommigen. Android telefoons die nog niet te roten waren kunnen nu geroot worden.

"Ook Red Hat, Debian en Ubuntu hebben fixes uitgebracht."
(open)SUSE niet?

Aanvulling: Ook (open)SUSE natuurlijk.
Goede lijst en uitleg voor meeste distro's hier

[Reactie gewijzigd door Anoniem: 719316 op 21 oktober 2016 15:52]

Het is gefixt?
Potverdorie, dat zal de Nederlandse politie(k) niet leuk vinden!

Ik wel, uiteraard.

[Reactie gewijzigd door tc-t op 21 oktober 2016 14:32]

Het is gefixt?
Potverdorie, dat zal de Nederlandse politie(k) niet leuk vinden!

Ik wel, uiteraard.

Ik denk dat deze bug maar beperkt interessant is voor geheime diensten. Omdat user moet zijn of commando's op het systeem moet kunnen uitvoeren.

Exploits waar over het netwerk direct root kunt worden zijn voor hun veel interresanter.

Net gechecked, lijkt erop dat Raspbian de fix nog niet in de sources heeft staan. Lijk me wel een belangrijk platform, aangezien de pi's overal en nergens worden ingezet en aan het internet hangen.

Iedereen zit hier maar te kankeren op Microsoft en linux, maar wat te denken van de zogenaamde "veiligheidsdiensten" die zulke dingen niet rapporteren aan de ontwikkelaars om er zelf zolang mogelijk gebruik te kunnen maken ?