Beveiligingsexperts van Google hebben een groot beveiligingslek ontdekt in glibc, de C library op de meeste Linux distributies. Door dit lek te misbruiken kan er code worden uitgevoerd op het systeem van de gebruiker om hiermee vervolgens toegang te krijgen tot het hele systeem. Er is al een nieuwe glibc gepubliceerd die het lek fixt. Maar dit installeren is niet genoeg: alle processen die draaien, gebruiken libc, en hebben de oude versie geladen. Dus je moet ieder proces herstarten om de kwetsbaarheid kwijt te raken. Snelle actie is dus geboden.
Achtergrond
De C library is een standaard library in het POSIX model, die veel standaardfuncties biedt en ook de interfacing naar de kernel regelt (syscalls gaan ook door libc heen). FreeBSD en OS X gebruiken een andere libc, en embedded systemen vaak ook, maar glibc is wel de bekendste libc inmiddels (mede dankzij haar excentrieke projectleider Ulrich Drepper). De C library bevat simpele functies voor string-manipulatie, maar ook functies voor het resolven van hostnames naar IP-adressen via het DNS systeem. Voor dat laatste wordt getaddrinfo() gebruikt (voorheen gethostbyname()).
De kwetsbaarheid
Met de komst van IPv6 moest een hoop code herzien worden: adressen zijn ineens soms 128 bits in plaats van altijd 32. Dat heeft al tot interessante kwetsbaarheden geleid, en dit is er ook weer zo een. Ergens diep in getaddrinfo() wordt bij het toewijzen van geheugenruimte voor een response waar IPv6-adressen in staan, wel genoeg ruimte gereserveerd op de heap, maar het betreffende DNS-antwoord wordt daarna alsnog op een te klein plekje op de stack opgeslagen. Met een buffer overflow als gevolg [1].
De impact
De stack overflow kan worden misbruikt om code executie mee te bereiken, enigszins afhankelijk van de omstandigheden. De aanvaller moet om de kwetsbaarheid te kunnen misbruiken, wel een DNS response naar het betreffende systeem kunnen beïnvloeden. Dus hij moet eerst een uitgaand DNS request triggeren (b.v. op een mailserver door een email naar zichzelf te laten sturen, of een HTTP request waarna Apache een reverse hostname gaat opzoeken). Vervolgens moet hij zijn (ongeldige) antwoord bij het kwetsbare systeem krijgen. Dat is niet onmogelijk, maar ook niet triviaal.
Als het lukt, moet hij een exploit hebben om de moderne protectiemechanismes te omzeilen: NX, ASLR, stack cookies etc. Google heeft een werkende PoC, dus het kan, maar vereist wel wat expertise. Totdat de eerste z’n exploit online gooit natuurlijk.
De mitigatie
Er is een nieuwe glibc gepubliceerd die het lek fixt. Die installeren is niet genoeg: alle processen die draaien, gebruiken libc, en hebben de oude versie geladen. Dus je moet ieder proces herstarten om de kwetsbaarheid kwijt te raken. Praktischer is het om elk proces te herstarten dat met data van buitenaf werkt (“init” is minder belangrijk dan “httpd”), en op een handiger moment gewoon te rebooten zodat je zeker weet dat alle cache weg is.
Tot die tijd kun je ook een workaround implementeren [2]. Als je machines netjes via een resolver DNS doen, en die resolver weigert ongeldige replies, dan zit je ook goed. Wij hebben op onze hosting-netwerken firewall-rules geïmplementeerd die de ongeldige responses zouden moeten droppen. Dat is een tijdelijke workaround totdat we kunnen patchen en rebooten, waar we nu druk mee zijn.
Voor informatie kun je uiteraard bij ons terecht.
[1] https://googleonlinesecurity.blogspot.nl
[2] https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
