Beheer

Security
Java

Ook oudere Java-installaties krijgen kritieke Log4j-patches

Week 2 in het lopende securitydrama rond wijdverspreide loggingtool Log4j.

© Oracle
24 december 2021

Week 2 in het lopende securitydrama rond wijdverspreide loggingtool Log4j.

De crisis met de kwetsbare loggingsoftware Log4j raakt niet alleen gebruikers van de nieuwste versie draaiend op een actuele versie van Java. Ook oudere Java-installaties met daarop oudere Log4j-versies krijgen updates. Deze patches dichten gaten die niet zo ernstig zijn als de grote Log4Shell-kwetsbaarheid maar de loggingtool 'geniet' wel de aandacht van kwaadwillenden.

Naast het traject van drie snel opeenvolgende spoedpatches voor de courante Log4j-versie zijn er ook enkele updates uitgekomen voor oudere versies. Nee, niet voor de óude 1x-reeks. Want die wordt al bijna zesenhalf jaar niet meer ondersteund, en heeft al ruim 9,5 jaar geen release meer gehad. Maar belangrijker nog: in de 1.x-reeks ontbreekt de functionaliteit waarin de grote Log4Shell-kwetsbaarheid schuilt. En dat gat, waarlangs op afstand eigen code valt uit te voeren, is juist het grote gevaar. Maar er is meer aan de hand met Log4j.

Java in de versnelling

De loggingtool, die draait op het Java-platform, is namelijk qua releases meegegaan met het releasetempo van die programmeertaal annex computingplatform. Eigenaar Oracle heeft dat tempo begin 2018 in hogere versnelling gezet. Dit nadat het ontwikkelen van grote nieuwe Java-releases (geteld in hele versienummers, dus vóór de punt) nogal moeizaam was verlopen en flink uitliep.

Java-software Log4j is met nieuwere versies meegegaan in de evolutie van dat onderliggende platform. Maar andersom gesteld betekent dat ook: oudere versies zijn achtergebleven. Zo is Log4j 2.12 beperkt tot draaien op Java 7, en draait 2.15 (en hoger) op Java 8. In de praktijk zijn er nog genoeg organisaties die zo'n relatief oude Java-versie als platform in gebruik hebben. Sterker nog, er zijn ook Log4j-gebruikers die nog op de 1.x-versie zitten.

Onwetend gebruiker zijn

Dat gebruik van oude, al dan niet verlaten, versies is niet in alle gevallen direct aan die gebruikende organisaties te wijten. Een flink deel van het gevaar nu met de Log4j-kwetsbaarheden zit 'm namelijk in het feit dat de opensourcetool is omarmd door diverse leveranciers van softwarepakketten en ook hardware-appliances. Log4j kan een ingrediënt zijn in een ander ICT-product, waarbij de daadwerkelijke gebruiker daarvan dat niet per se hoeft te weten.

De hoeveelheid Log4j-gebruikende producten is indrukwekkend, ook qua het aantal verschillende leveranciers. Zie maar de lange lijst die het Nationaal Cyber Security Centrum heeft aangelegd en die het ook aanvult. Op die lijst staan inmiddels vier verschillende kwetsbaarheden (elk met eigen CVE-nummer aangeduid) vermeld voor Log4j. Afhankelijk van de gebruikte versie kan er wel of geen sprake zijn van één of meer van de genoemde kwetsbaarheden.

Gat na gat na gat

Let op: dit betreft niet puur en alleen versies van vóór de ontdekking van de kritieke Log4Shell-kwetsbaarheid. Na het publiekelijk bekend worden van dat RCE-beveiligingsgat (remote code execution) zijn nog kwetsbaarheden gevonden waarmee een systeem of service onderuit valt te halen. Een DoS-aanval (denial-of-service) dus.

Deze minder ernstige kwetsbaarheid - die nog altijd serieus genomen moet worden - is CVE-2021-45105, waarvoor patches zijn uitgekomen. Jawel, meervoud. Het zijn namelijk Log4j-versies 2.17.0 en 2.12.2. Laatstgenoemde is dus voor de oudere 2.12-serie die draait op het oudere Java 7.

De oorspronkelijke 0-day Log4Shell is getooid met CVE-nummer 2021-44228. Deze is van toepassing op bèta9 van Log4j 2.0tot en met 2.12.1 én 2.13.0 tot en met 2.15.0. De 2.16.0-patch plus de 2.12.1-patch zijn toen gauw uitgebracht. Daarna is echter ontdekt dat deze patch die het RCE-gat moest dichten niet helemaal afdoende was. In bepaalde, non-standaard configuraties was er nog altijd sprake van RCE-gevaar. En zo is kwetsbaarheid CVE-2021-45046 'geboren'.

Echt oude versies

Ondertussen is er ook nog een RCE-mogelijkheid gevonden in de oude Log4j-versie 1.2. Daar bestaat onder bepaalde omstandigheden ook het gevaar dat kwaadwillenden op afstand eigen code kunnen uitvoeren op een systeem waar Log4j draait. Deze kwetsbaarheid heeft CVE-nummer 2021-4104 gekregen.

Het volgen van de nummerbrij - zowel qua CVE's als ook qua Log4j-versies - is geen sinecure. En wie dacht dat het oudste versienummer voor het onderliggende Java-platform door de bejaardheid de dans ontspringt, vergist zich. Voor het op Java 6 draaiende oude Log4j 2.3 is ook een patch uitgebracht: 2.3.1. En dat is gedaan samen met update 2.12.3. Jawel, nog een punt-punt-release voor de loggingtool die draait op Java 7.

Naast het met spoed updaten van Log4j wordt ook updaten van het onderliggende Java-platform aangeraden. De timing van patches voor Log4j toont namelijk aan dat logischerwijs nieuwere versies voorrang hebben bij het ontwikkelen en uitbrengen van die gevaarfixende updates. Oudere versies, zeker op oudere ondergronden, volgen daarna.

Geen kerstreces?

Voor Log4j-gebruikende organisaties - plus hun ICT-leveranciers - betekent dat een iets langere periode waarin die gebruikers gevaar lopen, mogelijk ongezien en mogelijk zelfs onwetend. Maar terwijl het opsporen, identificeren en updaten van Log4j-versies al geen makkelijke opgave is, kan het upgraden van de Java-basis ook voor uitdagingen zorgen. En dat vlak voor kerst en voor sommige mensen een eindejaarsvakantie.

De onbetaalde opensourcedevelopers van Log4j hebben echter wel de moeite genomen om het écht oude Log4j op het écht oude Java 6 toch nog mee te nemen in de patch-stroom. Omdat het gevaar toch wel erg groot is. Dit overigens óók met het oog op de feestdagen waarin wellicht wat minder waakzaamheid of ICT-mankracht paraat staat. Cybercriminelen kiezen er dus misschien wel voor om 'door te werken' in de kerstperiode. De sombere verwachting is dan ook dat er de komende weken nog Log4j-vuurwerk gaat komen.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.