Gevaarlijk lek ontdekt in glibc-module van Linux
Toegevoegd door - Ariën -, 12 jaar geleden
Opnieuw is er een kwetsbaarheid ontdekt in een onderdeel van diverse Linux-distributies. Dit maar is de GNU c-Library het doelwit voor hackers. Kwaadwillenden kunnen in deze compiler-module zowel lokaal als op afstand een kwetsbaarheid misbruiken, zodat er een 'buffer overflow' kan worden veroorzaakt. Hiermee is het dan ook mogelijk om root-toegang tot het systeem te krijgen.
De bug is ontdekt door het beveiligingsbedrijf Qualys, die de ernstige bug tegenkwam tijdens een veiligheids-audit. Via een specifieke functie van de 'glibc'-module zou het mogelijk zijn om malafide code uit te voeren, bevestigen de onderzoekers. Deze bug zou al 15 jaar aanwezig zijn geweest, en is twee jaar geleden gepatched. Helaas is het lapmiddel om onduidelijke redenen niet bij elke distributie doorgevoerd, mogelijk zou het bestempeld zijn geweest als 'onkwetsbaar'.
Qualys noemt impact van de 15 jaar oude bug, die ze daarom 'Ghost' noemen enorm. Veel bestaande Linuxdistributies zouden hiervoor kwetsbaar zijn. Het zou onder meer om Debian 7, Red Hat Enterprise Linux 6 en 7, CentOS 5, 6 en 7 en Ubuntu 12.04. Inmiddels worden er al patches via de updatekanalen van apt-get en yum doorgevoerd.
Inmiddels hebben de beveiligingsonderzoeker al een exploit ontwikkeld die gericht is op de EXIM-mailservers, die zowel op de 32- als de 64-bits architectuur draait. Ook zal de exploit als module voor de populaire Metasploit-hackerstoolkit worden uitgebracht.
De onthulling van 'Ghost' is het derde gevaarlijke ontdekte lek in ongeveer een jaar tijd. Deze volgt in de lijn hiermee het Heartbleed-lek en de ShellShock bug op.
Gerelateerde nieuwsberichten
07/08/2023 Ontwikkelaar van Text-editor Vim overleden
07/04/2022 Privacy waarborgen aan de hand van 5 tips
24/02/2017 CloudFlare lekte gebruikersdata
Er zijn 25 reacties op 'Gevaarlijk lek ontdekt in glibcmodule van linux'
Tsss ... gaat goed :-/
Is er voor dit soort beveiligingsissues eigenlijk niet een automatische update-mode in Linux zodat je patches niet handmatig hoeft uit te voeren?
(Bedankt voor het melden Aar!)
Is er voor dit soort beveiligingsissues eigenlijk niet een automatische update-mode in Linux zodat je patches niet handmatig hoeft uit te voeren?
(Bedankt voor het melden Aar!)
0 
-0 
-0
Voor diegenen die willen testen of zijn Linux server/computer kwetsbaar is: http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/
0 -0
-0
Frank (of iemand anders) ik heb de update uit jouw link uitgevoerd op Centos7. Ik zie nog steeds dezelfde ldd versie staan (2.17) na de reboot. Ik zag een verwijzing naar deze pagina: https://rhn.redhat.com/errata/RHSA-2015-0092.html waar je kunt zien of jouw versie gepatched is, maar ik weet eigenlijk niet hoe dat werkt. Weet jij dat?
By the way ... om zo'n lek te misbruiken, moet je dan SSH of FTP toegang hebben, of kan het ook via de browser?
By the way ... om zo'n lek te misbruiken, moet je dan SSH of FTP toegang hebben, of kan het ook via de browser?
0 -0
-0
Het lijkt erop dat je met een firewall-instelling ook het lek kan uitschakelen, gezien de bug in een DNS-resolver zit.
Mijn webhosting heeft op deze manier alle VPS'sen van zijn klanten 'gepatched'.
Naar verluidt zou je ook via een mail die door EXIM wordt verwerkt (op de meeste servers) kunnen exploiten. Een beetje dezelfde techniek als een willekeurig .cgi bestand met de ShellShock-bug van een tijdje geleden.
Mijn webhosting heeft op deze manier alle VPS'sen van zijn klanten 'gepatched'.
Naar verluidt zou je ook via een mail die door EXIM wordt verwerkt (op de meeste servers) kunnen exploiten. Een beetje dezelfde techniek als een willekeurig .cgi bestand met de ShellShock-bug van een tijdje geleden.
0 -0
-0
Ik vind dit soort lekken altijd lastig te plaatsen. Wanneer wordt een lek actief. Als iemand je SSH shell in kan komen? Als iemand via FTP toegang heeft? Of kan iedere scriptkiddie op de een of andere manier zo'n lek misbruiken?
Al met al, ik heb dus die yum update gedaan, maar hoe zie ik nu of het lek verholpen is? Volgens mij zou ik dat hier https://rhn.redhat.com/errata/RHSA-2015-0092.html ergens uit moeten kunnen afleiden, maar ik weet eerlijk gezegd niet hoe.
Al met al, ik heb dus die yum update gedaan, maar hoe zie ik nu of het lek verholpen is? Volgens mij zou ik dat hier https://rhn.redhat.com/errata/RHSA-2015-0092.html ergens uit moeten kunnen afleiden, maar ik weet eerlijk gezegd niet hoe.
@Ozzie,
De reden dat ldd nog steeds v2.17 laat zien, is omdat bij CentOS security fixes worden gebackport. In verband met mogelijke compatibiliteits-issues zal daar niet zomaar een upgrade naar een nieuwe versie worden gedaan. Bij andere distributies kan dat ook zijn.
Om te controleren of je de update al hebt, moet je op de link die je geeft zoeken naar je distributie. CentOS 7 staat daar niet tussen, maar die komt overeen met Red Hat Enterprise Linux Server v7. Zoek daar naar je architectuur (dat zal meestal i386 of x86_64 zijn, maar als je het niet weet, kun je het achterhalen met het commando "uname -p"). Je ziet dan een overzicht van packages en hun versies.
Met "yum list installed" kun je vervolgens kijken wat er geïnstalleerd is. Bij mij staat daar bijvoorbeeld iets als:
glibc.x86_64 2.17-55.el7_0.5
glibc-common.x86_64 2.17-55.el7_0.5
Dit komt overeen met wat op de RH-site staat:
glibc-2.17-55.el7_0.5.x86_64.rpm
glibc-common-2.17-55.el7_0.5.x86_64.rpm
Oftewel: alles is OK.
De reden dat ldd nog steeds v2.17 laat zien, is omdat bij CentOS security fixes worden gebackport. In verband met mogelijke compatibiliteits-issues zal daar niet zomaar een upgrade naar een nieuwe versie worden gedaan. Bij andere distributies kan dat ook zijn.
Om te controleren of je de update al hebt, moet je op de link die je geeft zoeken naar je distributie. CentOS 7 staat daar niet tussen, maar die komt overeen met Red Hat Enterprise Linux Server v7. Zoek daar naar je architectuur (dat zal meestal i386 of x86_64 zijn, maar als je het niet weet, kun je het achterhalen met het commando "uname -p"). Je ziet dan een overzicht van packages en hun versies.
Met "yum list installed" kun je vervolgens kijken wat er geïnstalleerd is. Bij mij staat daar bijvoorbeeld iets als:
glibc.x86_64 2.17-55.el7_0.5
glibc-common.x86_64 2.17-55.el7_0.5
Dit komt overeen met wat op de RH-site staat:
glibc-2.17-55.el7_0.5.x86_64.rpm
glibc-common-2.17-55.el7_0.5.x86_64.rpm
Oftewel: alles is OK.
@Ozzie:
In je eerste reactie stel je een vraag over automatische updates. Daarvoor moet je de package yum-cron installeren. Vervolgens kun je in /etc/yum/yum-cron.conf aangeven welke updates je wilt installeren (alles, alleen security, etc) en of je meteen wilt updaten of alleen maar een notificatie wilt hebben dat er iets te updaten valt.
@Aar: Volgens mij is dit niet een bug die je via een firewall-instelling kunt patchen, tenzij je met die firewall de volledige toegang tot je systeem wilt afsluiten. ;-)
In je eerste reactie stel je een vraag over automatische updates. Daarvoor moet je de package yum-cron installeren. Vervolgens kun je in /etc/yum/yum-cron.conf aangeven welke updates je wilt installeren (alles, alleen security, etc) en of je meteen wilt updaten of alleen maar een notificatie wilt hebben dat er iets te updaten valt.
@Aar: Volgens mij is dit niet een bug die je via een firewall-instelling kunt patchen, tenzij je met die firewall de volledige toegang tot je systeem wilt afsluiten. ;-)
0 -0
-0
Willem, fijn dat je even de tijd hebt genomen om te reageren! Mijn versienummers komen precies overeen met die van jou. Dat zit dus goed. Ik heb trouwens ook nog een glib2 ertussen staan, maar die heeft er denk ik niks mee te maken?
Dat yum-cron lijkt me handig om te installeren! Zitten daar nog nadelen aan? Kan het je systeem in de war gooien? Wat raad jij aan, direct updates installeren of alleen notificaties ontvangen?
En mijn eerdere vraag, weet jij daar het antwoord op? Wanneer kan zo'n lek misbruikt worden? Moet iemand dan eerst toegang tot SSH of FTP verkrijgen?
Dat yum-cron lijkt me handig om te installeren! Zitten daar nog nadelen aan? Kan het je systeem in de war gooien? Wat raad jij aan, direct updates installeren of alleen notificaties ontvangen?
En mijn eerdere vraag, weet jij daar het antwoord op? Wanneer kan zo'n lek misbruikt worden? Moet iemand dan eerst toegang tot SSH of FTP verkrijgen?
Ik heb met een collega zitten overleggen en googlen en we zijn er beide niet zeker van in hoeverre deze bug remote (zonder eerst een shell op het systeem te hebben) kan worden geëxploiteerd. Alleen EXIM schijnt momenteel enigszins vatbaar te zijn, en dan ook nog alleen wanneer je HELO-identificatie aan hebt staan. Maarrrr... dat er geen exploit is gevonden wil niet zeggen dat 'ie er niet is. ;-) Updaten is dus sowieso aan te bevelen.
glib2 is iets heel anders dan glibc. Heeft er inderdaad niets mee te maken. glibc is een library met system calls en glib2 een library met utilities.
Qua yum-cron: zelf heb ik hem in standje 'notify and download' staan. Updates worden wel gedownload, maar niet geïnstalleerd. In mijn mailbox zie ik een mailtje langskomen dat er updates zijn en als ik vind dat het nodig is, doe ik een update. Ik heb iets tegen automatische updates. ;-) Overigens is de frequentie waarmee updates voor CentOS worden gereleased een stuk kleiner dan bij een wat meer cutting-edge-distro als Fedora. Je hebt er dus geen dagtaak aan als je de updates handmatig moet verwerken.
glib2 is iets heel anders dan glibc. Heeft er inderdaad niets mee te maken. glibc is een library met system calls en glib2 een library met utilities.
Qua yum-cron: zelf heb ik hem in standje 'notify and download' staan. Updates worden wel gedownload, maar niet geïnstalleerd. In mijn mailbox zie ik een mailtje langskomen dat er updates zijn en als ik vind dat het nodig is, doe ik een update. Ik heb iets tegen automatische updates. ;-) Overigens is de frequentie waarmee updates voor CentOS worden gereleased een stuk kleiner dan bij een wat meer cutting-edge-distro als Fedora. Je hebt er dus geen dagtaak aan als je de updates handmatig moet verwerken.
0 -0
-0
Dankjewel Willem! Mag ik vragen waarom je de updates wel altijd download? Blijf je dan niet met "troep" achter indien je ze niet installeert?
0 -0
-0
Dat downloaden doe ik eigenlijk voornamelijk zodat ik dan niet zit te wachten op het downloaden als ik de updates installeer. Ook al heb ik de fastestmirror-plugin, toch tref ik wel eens een trage uplink. En troep... als je alle updates uiteindelijk een keer installeert, blijft er geen troep achter. ;-)
0 -0
-0
Ah oké, dan heb ik je verkeerd begrepen :-) Ik dacht eigenlijk dat je bedoelde dat je sommige updates wel installeert en andere updates helemaal niet. Maar als ik je nu goed begrijp, installeer je uiteindelijk gewoon alle updates. Correct?
0 -0
-0
Klopt. Ik installeer ze uiteindelijk allemaal, alleen wil ik wel graag zelf bepalen wanneer. Zeker op productiesystemen wil ik graag de mogelijkheid hebben om erbij te zijn als er iets omvalt. ;-) Het kan dus ook zijn dat ik afhankelijk van nut en noodzaak sommige updates wel installeer en andere nog een maandje laat wachten.
0 -0
-0
Ozzie,
Ik lees je vraag nu pas. Maar ik geloof dat Willem die beantwoord heeft en dat zou ik niet zo compleet kunnen als hem (Bedankt Willem).
Ik lees je vraag nu pas. Maar ik geloof dat Willem die beantwoord heeft en dat zou ik niet zo compleet kunnen als hem (Bedankt Willem).
Voor de liefhebbers die willen weten of ze kwetsbaar zijn:
Dit uitvoeren in SSH, en je ziet of je geraakt kan worden.
Code (php)
1
wget -q https://gist.githubusercontent.com/amlweems/6e78d03810548b4867d6/raw/69e2fb429dc6f020954405a9d55021db8db1d26e/gistfile1.c -O ghost.c && gcc ghost.c -o GHOST && ./GHOST
Dit uitvoeren in SSH, en je ziet of je geraakt kan worden.
0 -0
-0
@ Willem:
>> ... sommige updates wel installeer en andere nog een maandje laat wachten.
Kun je dan ook op een of andere manier zien welke updates zijn gedownload maar nog niet geinstalleerd? En worden die updates na het installeren eigenlijk vanzelf van je server verwijderd, of blijven ze erop staan?
@Aar:
Als ik dat invoer zegt ie:
"-bash: gcc: opdracht niet gevonden"
>> ... sommige updates wel installeer en andere nog een maandje laat wachten.
Kun je dan ook op een of andere manier zien welke updates zijn gedownload maar nog niet geinstalleerd? En worden die updates na het installeren eigenlijk vanzelf van je server verwijderd, of blijven ze erop staan?
@Aar:
Als ik dat invoer zegt ie:
"-bash: gcc: opdracht niet gevonden"
0 -0
-0
@Ozzie:
Volgens mij heeft yum geen mogelijkheid om te laten zien welke packages zijn gedownload. Wel kun je met 'yum list' zien of er updates zijn van geïnstalleerde packages: die zijn dan highlighted.
Als je een update van een package hebt gedaan, wordt de rpm verwijderd. In sommige gevallen kan de rpm in de cache achterblijven. De gemakkelijkste manier die ik ken om te zien wat er is gedownload, is het commando "find /var/cache/yum -name \*.rpm"
Met 'yum clean packages' kun je de rpms uit de cache verwijderen.
Volgens mij heeft yum geen mogelijkheid om te laten zien welke packages zijn gedownload. Wel kun je met 'yum list' zien of er updates zijn van geïnstalleerde packages: die zijn dan highlighted.
Als je een update van een package hebt gedaan, wordt de rpm verwijderd. In sommige gevallen kan de rpm in de cache achterblijven. De gemakkelijkste manier die ik ken om te zien wat er is gedownload, is het commando "find /var/cache/yum -name \*.rpm"
Met 'yum clean packages' kun je de rpms uit de cache verwijderen.
0 -0
-0
>> Met 'yum clean packages' kun je de rpms uit de cache verwijderen.
Kan je dat ook via bijv. WinSCP doen door de files gewoon te verwijderen (of maak je dan iets kapot)?
Ik zag trouwens in de instructies van hoe je moet updaten, dat er eerst yum clean all werd gedaan. Waar is dat nuttig voor?
Het is wel een hoop gekkigheid hoor met dat yum :)
Kan je dat ook via bijv. WinSCP doen door de files gewoon te verwijderen (of maak je dan iets kapot)?
Ik zag trouwens in de instructies van hoe je moet updaten, dat er eerst yum clean all werd gedaan. Waar is dat nuttig voor?
Het is wel een hoop gekkigheid hoor met dat yum :)
0 -0
-0
Het lijkt me geen probleem om de bestanden met WinSCP weg te gooien; het is gewoon gecachte data, dus het is er of het is er niet, en als het er niet is wordt het gedownload als je het nodig hebt. Maar als je alleen de packages wilt weggooien en niet de database moet je wel een beetje door de directoryboom navigeren. Vooral als je wat extra repositories gebruikt is dat meer werk dan inloggen en yum clean starten. :-)
Ik gok dat die 'clean all' wordt gedaan om te forceren dat yum geen gecachte informatie gebruikt (zodat je niet per ongeluk een package installeert waar alweer nieuwere updates voor zijn). Zelf doe ik het eigenlijk nooit; ik ga eigenlijk nooit verder dan 'yum clean metadata', en dan ook nog alleen als er problemen zijn.
> Het is wel een hoop gekkigheid hoor met dat yum
En dan te bedenken dat yum -in mijn ogen- nog de meest gebruikersvriendelijke package manager is die in de verschillende distributies wordt gebruikt. Als je het geluk hebt om met een keer met apt of conary te moeten werken, weet je wel wat ik bedoel. ;-)
Ik gok dat die 'clean all' wordt gedaan om te forceren dat yum geen gecachte informatie gebruikt (zodat je niet per ongeluk een package installeert waar alweer nieuwere updates voor zijn). Zelf doe ik het eigenlijk nooit; ik ga eigenlijk nooit verder dan 'yum clean metadata', en dan ook nog alleen als er problemen zijn.
> Het is wel een hoop gekkigheid hoor met dat yum
En dan te bedenken dat yum -in mijn ogen- nog de meest gebruikersvriendelijke package manager is die in de verschillende distributies wordt gebruikt. Als je het geluk hebt om met een keer met apt of conary te moeten werken, weet je wel wat ik bedoel. ;-)
0 -0
-0
Haha ... naja ... het is allemaal nog een beetje nieuw met dat yum. Als je eenmaal weet hoe het werkt valt het waarschijnlijk wel mee. Maar zou je kunnen stellen dat yum eigenlijk het belangrijkste is waar je het meest mee te maken hebt als je een eigen server hebt?
0 -0
-0
Ja, het is DE updates-service voor je server. Elke package die je maar installeert via YUM (soms door het toevoegen van een extra repo) zal worden gecontroleerd als je op updates controleert.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu