Gevaarlijk lek ontdekt in glibc-module van Linux

Toegevoegd door - Ariën -, 11 jaar geleden

Gevaarlijk lek ontdekt in glibc-module van LinuxOpnieuw 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'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
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!)
Frank Nietbelangrijk
Frank Nietbelangrijk
11 jaar geleden
 
0 +1 -0 -1
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/
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
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?
- Ariën  -
- Ariën -
11 jaar geleden
 
0 +1 -0 -1
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.
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
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.
Johan de wit
johan de wit
11 jaar geleden
 
0 +1 -0 -1
Ozzie dat vraag ik mij ook af.
Willem vp
Willem vp
11 jaar geleden
 
1 +1 -0 -1
@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.
Willem vp
Willem vp
11 jaar geleden
 
1 +1 -0 -1
@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. ;-)
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
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?
Willem vp
Willem vp
11 jaar geleden
 
1 +1 -0 -1
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.
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
Dankjewel Willem! Mag ik vragen waarom je de updates wel altijd download? Blijf je dan niet met "troep" achter indien je ze niet installeert?
Willem vp
Willem vp
11 jaar geleden
 
0 +1 -0 -1
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. ;-)
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
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?
Willem vp
Willem vp
11 jaar geleden
 
0 +1 -0 -1
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.
Frank Nietbelangrijk
Frank Nietbelangrijk
11 jaar geleden
 
0 +1 -0 -1
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).
- Ariën  -
- Ariën -
11 jaar geleden
 
1 +1 -0 -1
Voor de liefhebbers die willen weten of ze kwetsbaar zijn:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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.
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
@ 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"
- Ariën  -
- Ariën -
11 jaar geleden
 
0 +1 -0 -1
Dan heb je blijkbaar geen gcc?
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
Oooh ... blijkbaar dan :-/
Ik weet ook niet wat dat is.
Willem vp
Willem vp
11 jaar geleden
 
0 +1 -0 -1
@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.
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
>> 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 :)
Willem vp
Willem vp
11 jaar geleden
 
0 +1 -0 -1
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. ;-)
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
0 +1 -0 -1
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?
- Ariën  -
- Ariën -
11 jaar geleden
 
0 +1 -0 -1
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.
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Ozzie PHP
Ozzie PHP
11 jaar geleden
 
1 +1 -0 -1
Oké, thanks.

Om te reageren heb je een account nodig en je moet ingelogd zijn.

Labels

PHP nieuws opties

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.