Linux-kernel kwetsbaar voor denial of service
Beveiligingsonderzoeker Juha-Matti Tilli heeft een kwetsbaarheid in de Linux-kernel ontdekt waardoor een aanvaller bij systemen met een open poort een denial of service kan veroorzaken. Hiervoor moet een aanvaller binnen een lopende tcp-sessie speciaal geprepareerde pakketten versturen.
Deze pakketten kunnen het geheugen van de server zodanig belasten dat er 'resource exhaustion' ontstaat en het systeem traag of onbereikbaar wordt. Om de denial of service te laten voortduren is een two-way tcp-sessie naar een bereikbare open poort vereist. "Dus de aanvallen zijn niet via gespoofte ip-adressen uit te voeren", aldus het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit. Het probleem is aanwezig in Linux-kernel 4.9 en nieuwer. Het CERT/CC meldt dat er patches beschikbaar zijn om de kwetsbaarheid te verhelpen.
Reacties (11)
07-08-2018, 21:17 door
Eric-Jan H te D
Aangenaam weinig reacties :-D
Door Eric-Jan H te A: Aangenaam weinig reacties :-D
Een kwetsbaarheid, kan gebeuren. Er is al een patch, probleem waarschijnlijk opgelost. Ik wacht nog op een update van de Manjaro kernel, ik draai 4.14 LTS. Heeft ook geen haast voor mij, dit betreft alleen servers, desktops hebben standaard geen poorten open staan.
Gelukkig hebben ze bij Linux geen "patch tuesday". Anders zouden we nog een maand lang moeten wachten totdat deze kwetsbaarheid gefixt zou zijn. Maar nee... ik lees dit, en besef dat ik de patch al geïnstalleerd had bij het opstarten van mijn computer.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
08-08-2018, 08:38 door
karma4
Door Anoniem: Gelukkig hebben ze bij Linux geen "patch tuesday". Anders zouden we nog een maand lang moeten wachten totdat deze kwetsbaarheid gefixt zou zijn. Maar nee... ik lees dit, en besef dat ik de patch al geïnstalleerd had bij het opstarten van mijn computer.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Alleen wordt het met Linux nooit uitgerold. IOT mist patch beleid, servers zijn te kritisch om een patch ongetest door te laten gaan. Het zal nog jaren blijven zitten. Als je iets automatisch laat installeren heb je het open staan om gehacked te worden.Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Door karma4:
Door Anoniem: Gelukkig hebben ze bij Linux geen "patch tuesday". Anders zouden we nog een maand lang moeten wachten totdat deze kwetsbaarheid gefixt zou zijn. Maar nee... ik lees dit, en besef dat ik de patch al geïnstalleerd had bij het opstarten van mijn computer.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Alleen wordt het met Linux nooit uitgerold. IOT mist patch beleid, servers zijn te kritisch om een patch ongetest door te laten gaan. Het zal nog jaren blijven zitten. Als je iets automatisch laat installeren heb je het open staan om gehacked te worden.Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Patches worden bij Linux nooit zomaar ongetest en automatisch geïnstalleerd bij het opstarten. Geen idee wat Anoniem @03:48 voor Linux systeem heeft. Ik draai Manjaro Linux en heb nog geen patch gezien. Waarom niet? Omdat hij eerst door het Manjaro Team getest wordt voordat hij bij de stabiele updates aangeboden wordt. Daarna beslis ik zelf wanneer ik 'm instaleer. Maar dat is meestal meteen omdat hij al getest is.
Wat ik met anoniem eens ben is dat "Patch Tuesday" compleet achterlijk is en niets te maken heeft met het feit dat updates in een groot bedrijf eerst getest moeten worden voordat ze enterprise wide uitgerold worden. Ja zonder patch tuesday zullen de IT jongetjes meerdere keren per maand updates moeten testen i.p.v. op een vast maandelijks tijdstip na patch tuesday, goed voor ze, dat is hun werk!
Als je iets automatisch laat installeren loop je hoogstens de kans op instabiliteit, niet om gehacked te worden.
En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
08-08-2018, 12:18 door
karma4
Door linux4:
En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
Ik niets met Windows. Ik zie de ellende met data analyses gegevensverwerkingen. Daar wordt Linux als schaamlapje gebruikt om als ontwikkelaars niet aan security informatieveiligheid te doen. Dat wordt verergerd aan de onwil van Linux nerd om mee te denken over betere oplossingen voor de op te lossen vraagstukken. En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
Zoals je aantoont elke vorm wat op kritiek zou kunnen duiden wordt afgedaan als "windows aanhang". Dat brengt geen verbetering, integendeel.
"Als je iets automatisch laat installeren loop je hoogstens de kans op instabiliteit, niet om gehacked te worden."
ik kan je uit profesionele ervaring vertellen op bijv CentOS / RHEL dat je de yum update vol automatisch aan kunt zetten via cron dagelijks als je je beperkt tot de nette officiele distro en epel repos en yum protection van die repos gebruikt. In de 20j ervaring heb ik nog geen 'rotte' update ervaren op servers en of op werkstations (>400 en dat zlefs met de meltdown/spectre rotte microcodes fase begin dit jaar van Intel) en hoewel in theorie inderdaad er eens een rotte update voorbij zou kunnen komen, denk ik persoonlijk dat 20j RHVE up to date zijn de resources/fte ballans nu al gunstig maakt als er vannacht ineens op alle servers zo een rotte update binnen zou komen. Maargoed dat is slechts mijn ervaring / risico analyse en die is niet een one size fits all voor iedereen, maar om nu zo uptight over die ene mogelijk rotte update in theorie te doen vind ik dus ook enigsinds overtrokken en heb ervaring en data om die stelling te ondersteunen. ook is een bekende rotte update eenvoudig tegengehouden met bijv yum versionlock danwel een rollback te doen via yum history undo. verschilletje tussen theorie en praktijk ervaring?
ik kan je uit profesionele ervaring vertellen op bijv CentOS / RHEL dat je de yum update vol automatisch aan kunt zetten via cron dagelijks als je je beperkt tot de nette officiele distro en epel repos en yum protection van die repos gebruikt. In de 20j ervaring heb ik nog geen 'rotte' update ervaren op servers en of op werkstations (>400 en dat zlefs met de meltdown/spectre rotte microcodes fase begin dit jaar van Intel) en hoewel in theorie inderdaad er eens een rotte update voorbij zou kunnen komen, denk ik persoonlijk dat 20j RHVE up to date zijn de resources/fte ballans nu al gunstig maakt als er vannacht ineens op alle servers zo een rotte update binnen zou komen. Maargoed dat is slechts mijn ervaring / risico analyse en die is niet een one size fits all voor iedereen, maar om nu zo uptight over die ene mogelijk rotte update in theorie te doen vind ik dus ook enigsinds overtrokken en heb ervaring en data om die stelling te ondersteunen. ook is een bekende rotte update eenvoudig tegengehouden met bijv yum versionlock danwel een rollback te doen via yum history undo. verschilletje tussen theorie en praktijk ervaring?
Door karma4:
Zoals je aantoont elke vorm wat op kritiek zou kunnen duiden wordt afgedaan als "windows aanhang". Dat brengt geen verbetering, integendeel.
Door linux4:
En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
Ik niets met Windows. Ik zie de ellende met data analyses gegevensverwerkingen. Daar wordt Linux als schaamlapje gebruikt om als ontwikkelaars niet aan security informatieveiligheid te doen. Dat wordt verergerd aan de onwil van Linux nerd om mee te denken over betere oplossingen voor de op te lossen vraagstukken. En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
Zoals je aantoont elke vorm wat op kritiek zou kunnen duiden wordt afgedaan als "windows aanhang". Dat brengt geen verbetering, integendeel.
Alleen in jouw kleine wereldje! De kans dat dit aan jou ligt (bv. door een gebrek aan professioneel overwicht of overtuigingskracht - eigenlijk een beperkt ethos) is véél groter dan de kans dat dit met Linux te maken heeft.
Meeste systemen draaien toch niet eens de 4 kernel. EL/CentOS zitten nog op 2.6 en 3.10.
Door Anoniem: Meeste systemen draaien toch niet eens de 4 kernel. EL/CentOS zitten nog op 2.6 en 3.10.
maar het zou toevallig kunnen dat de 'bug' wel in de 3.10 gebackport was door RH.
deze lijkt bijv misschien wel van toepassing:
https://access.redhat.com/security/cve/cve-2018-5391
Door Anoniem:
maar het zou toevallig kunnen dat de 'bug' wel in de 3.10 gebackport was door RH.
deze lijkt bijv misschien wel van toepassing:
https://access.redhat.com/security/cve/cve-2018-5391
Door Anoniem: Meeste systemen draaien toch niet eens de 4 kernel. EL/CentOS zitten nog op 2.6 en 3.10.
maar het zou toevallig kunnen dat de 'bug' wel in de 3.10 gebackport was door RH.
deze lijkt bijv misschien wel van toepassing:
https://access.redhat.com/security/cve/cve-2018-5391
correctie https://access.redhat.com/security/cve/cve-2018-5390
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
