Red Hat komt met fix voor lek in Libxml2

Red Hat heeft als eerste softwareleverancier een update vrijgegeven naar aanleiding van een kritiek lek in Libxml2. Onder meer het Nationaal Cyber Security Centrum waarschuwde deze week voor de kwetsbaarheid in de bibliotheek voor het verwerken van xml-documenten.

Door het lek konden kwaadwillenden een dos-aanval bij webapplicaties veroorzaken. Het kwam aan het licht tijdens een reguliere veiligheidstest door Sogeti. De onderzoekers meldden de kwetsbaarheid bij het Nationaal Cyber Security Centrum, dat later met de waarschuwing kwam.

Het NCSC had de ontwikkelaars van Libxml2 op de hoogte gebracht van de kwetsbaarheid. Die kozen ervoor het lek publiek bekend te maken en ook een oplossing aan softwareleveranciers te bieden. Red Hat is daar nu de eerste van, zo werd bekend. Het bedrijf geeft drie Linuxdistributies uit: Red Hat Enterprise Linux, Fedora en CentOS.

Het Nationaal Cyber Security Centrum zegt tot slot de situatie nauwgezet te volgen. Volgens het centrum komen ook andere softwarepartijen met oplossingen voor het lek.

Reacties (22)

[Verwijderd]

Deze fix was volgens mij gisteren al beschikbaar
Altijd snel gefixed bij Red Hat.
Mijn laptop is weer up to date.

Uiteraard kost het een paar centen maar het werkt erg fijn RHEL 7.
En CentOS gebruikers zullen er ook wel snel van kunnen genieten!

[Blokker_1999]

Ik vind het vooral vreemd dat men ervoor kiest om hier specifiek RH te noemen daar de patch geschreven is door de lead developer van libxml2 (Daniel Veillard) en in eerste instantie gewoon in de git repo ervan is terechtgekomen. Het is ook diezelfde Daniel die de patches heeft gesubmit bij RH en zelf de backports heeft gedaan voor oudere versies van het OS.

De reden dat hij zelf die patches voor RH maakt is omdat RH zijn werkgever is, maar hij werkt niet voor RH vanwege die library natuurlijk, hij doet er wel wat ander werk ook. Andere distributies (betaald of gratis) zullen in de loop van de dag ook wel volgen met patches.

Ik zou persoonlijk RHEL/CentOS dan ook niet aanraden voor thuisgebruik. Het is een enterprise distributie en dat merk je wanneer je het gebruikt. Enorm gericht op het veilig werken waarbij je zelf bij network services altijd moet gaan instellen op welke ip/poort iets mag binden en op je firewall wat wel en wat niet mag. Heel tof en veilig voor bedrijven, iets minder voor een thuisgebruiker die een vlotte ervaring wenst.

[Verwijderd]

Draai jij een publiek toegankelijke webapp die xml van bezoekers parsed op je laptop?

[Verwijderd]

Nee hoor, maar ieder lek wat gedicht word is mooi meegenomen.
Daarbij vind ik het netjes hoe snel Red Hat dit soort dingen fixed.
Net als bij het POODLE lek... ook gelijk doorgevoerd op OpenShift.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:29]

[Verwijderd]

Die fix die ook beschikbaar is voor ALLE linux distributies? Ja super van red hat. Man wat een marketing feest weer.

[sgrinovero]

Iemand moet het code ook begrijpen, de patches naakijken en zorgen dat ze in de open source projected spoedig integreert worden, dat doen Red Hat engineers dan.
Inderdaad hun werk word in alle linux distributies beschikbaar gemaakt, niet alleen in hun eigen omdat ze "upstream first" als een mantra toepassen. Ik ben nu zelf een software engineer by Red Hat en trots hiervoor, maar ben ook met Tweakers.net opgegroeid :-)

[Verwijderd]

Zoal je zelf kunt lezen in het bovenstaande stukje tekst: Fedora en CentOS, en die zijn??? Juist opensource.
Dus iedereen kan er gebruik van maken, mooi he?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:29]

[Verwijderd]

Goed om te zien dat er de laatste tijd ook op Linux veel kwetsbaarheden worden platgeslagen.
Wat opvalt is dat er ondanks de volledig beschikbare broncode dit probleem meer dan 10 jaar kon bestaan, en zelfs nu lijkt het er op dat de bug in eerste instantie niet eens is ontdekt door het doorspitten van de code, maar door aanvalspogingen?
"tijdens een reguliere veiligheidstest"

Het voordeel van open source is dan weer wel dat de oorzaak te lokaliseren is; maar ook dit geval geeft maar weer eens aan hoe complex doorspitten van code om problemen te ontdekken in de praktijk is.

[Blokker_1999]

Open Source betekend nog niet dat mensen ook effectief de code doornemen. Bijkomend zijn er vele fouten waar men gewoonweg niet bij stilstaat en blijven deze dus bestaan. Het belangrijkste voordeel van FOSS is wel dat iedereen de broncode kan inkijken indien men dit wenst, dat men deze zelf kan compileren (en dus zeker is dat er geen backdoors inzitten) of dat men zelf aanpassingen kan maken (en dus ook bugfixes wanneer de code al jarenlang niet meer ondersteund word).

[begintmeta]

Onder de 'RHEL-kloons' CentOS, Oracle Linux en Scientific Linux lijkt de gepatchde versie inmiddels bij Oracle Linux het eerst beschikbaar te zijn. (vanaf gisteren)

[Reactie gewijzigd door begintmeta op 23 juli 2024 06:29]

[thegve]

Lol, CentOS een product van RedHat? Dacht het niet, CentOS is een community project dat de open source delen van RedHat Enterprise Linux (RHEL) build en hiermee binary-compatible is met RHEL.
Maar het is niet een RedHat project.

[!nFerNo]

vziw is CentOS "ingelijfd" door RedHat

In January 2014, it was announced that CentOS was officially joining forces with Red Hat while staying independent from RHEL,[7] under a new CentOS Governing Board.

[thegve]

Ok... Dat nieuwtje heb ik gemist.

[aadv]

Iets heel anders.
Ik zou er voor zijn om lekken en andere bugs enkel stil te melden aan de software - distroontwikkelaars.
Beheerders zijn dan verantwoordelijk of de uitgebrachte fix daadwerkelijk geinstalleerd wordt, kortom of zijn werk goed wordt gedaan.
Het met details uitleggen wat voor probleem er nu weer gevonden is is volgens mij enkel een aanzet voor huftertjes om te gaan proberen het lek te gebruiken.

[Blokker_1999]

Tjah, iedereen kan de code changes bekijken. Of je er nu beschijft wat je fixed of niet maakt niet uit. Securtty trough obscurity werkt trouwens niet. Het is niet omdat je het niet bekend maakt dat iemand anders er ook niet achter kan komen. Bijkomend dwingt het bekendmaken ontwikkelaars net om het gat zo snel mogelijk te dichten.

[Keypunchie]

Maar daar zit ook een balans in. Soms heb ik de indruk dat bij de gemiddelde Tweaker het idee heerst dat patches bij bedrijven soms lang duren om door te voeren omdat de beheerders lui/incompetent zijn.

In de praktijk is de wereld een stuk complexer. Ja, je hebt luie en incompetente beheerders, maar ook zeer pro-actieve en competente beheerders kunnen niet altijd zomaar een patch doorvoeren.

Om te beginnen heb je een SLA. Wanneer jij voor elk wissewasje gaat patchen kan dat onacceptable onbeschikbaarheid betekenen. Belangrijk natuurlijk om in SLA's ook je patchbeleid op te nemen, maar als dat niet goed afgedekt is, dan moet je als beheerder balans vinden tussen veiligheid en het nakomen van je SLA. In het geval van een bug als Heartbleed is het duidelijk, in een geval als Shellshock of Poodle veel minder.

Daarnaast en veel belangrijker is de complexiteit van omgevingen. Een patch kan zomaar gevolgen hebben voor andere, bedrijfskritische, software. Soms draai je een oude versie van een library of stuk software, omdat een nieuwere versie niet compatible is met jouw applicaties.

Als er dan in de oude versie een security issue wordt ontdekt, dan kun je niet direct patchen. De gevolgen van de patch zijn dan vervelend. In dit geval: de garantie dat je software niet werkt, vs. de mogelijke kans dat je via deze hoek geDDoS'd wordt.

Dat ontwikkelaars jouw applicatie dan maar zo snel mogelijk moeten bijwerken is ook weer nogal idyllisch gedacht. Die applicatie-ontwikkelaars hebben misschien een stuk contract-werk geleverd. Dan moet je budget vinden en de nieuwe ontwikkelaars moeten zich de code eigen maken. Of misschien is het extreem complexe software (niet voor niets had je het probleem nog niet eerder opgelost). Of misschien is de leverancier van de software al failliet.

Risico van de sector allemaal, maar om maar aan te geven dat de 'happy flow' van 'bug ontdekt' -> 'fix gemaakt' -> 'geinstalleerd' op een hele hoop punten spaak kan lopen, zelfs al is er goede wil en inzet van ontwikkelaars, beheerders en management.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 06:29]

[Blokker_1999]

Het is niet omdat men niet overal zo maar fixes/patches kan toepassen dat men dan ineens maar het bestaan van beveiligingsgaten moet gaan geheimhouden. Als we dat wel zouden doen dan kweken we niet alleen scheinveiligheid, maar zullen er ook minder goede beheerders zijn die het belang van systemen up-to-date te houden zullen vergeten.

Het zou zijn alsof we het bestaan van ziektes zoals AIDS of Ebola zouden verzwijgen voor de bevolking in de hoop dat er nooit een crimineel op het idee zou komen om deze ziektes te gaan misbruiken tegen de bevolking. Als je weet dat een kwetsbaarheid bestaat kan je jezelf er tegen wapenen, als men deze verzwijgt zorg je net voor een onveiligere wereld.

[jgk]

Let wel RHEL 6 en RHEL 7 patched rpms zijn beschikbaar, een patched rpm voor RHEL 5 is nog niet uitgebracht.