Google maakt met OSS-Fuzz continu testen op Log4j-kwetsbaarheden mogelijk

Google gaat samen met beveiligingsbedrijf Code Intelligence zijn OSS-Fuzz-dienst naar voren schuiven om Log4j continu op kwetsbaarheden te kunnen testen. Met de Jazzer-fuzzingengine is te detecteren of er JNDI-look-ups plaatsvinden.

Google wil met zijn aanpassingen aan de gratis fuzzingdienst OSS-Fuzz naar eigen zeggen opensource-ontwikkelaars de mogelijkheid bieden zelf hun code veiliger te maken. De continue fuzzing van Log4j is een eerste stap. Het komende jaar wil het Google Open Source Security Team aan betere geautomatiseerde detectie van kwetsbaarheden zoals Log4Shell werken.

Met fuzzing testen bedrijven software geautomatiseerd op bugs door deze te bestoken met inputs. Google introduceerde in 2016 de OSS-Fuzz-dienst waarmee projecten zo continu op fouten kunnen testen. Volgens het bedrijf hebben inmiddels meer dan vijfhonderd opensourceprojecten de dienst gebruikt en zijn er meer dan zevenduizend kwetsbaarheden mee gevonden. Begin dit jaar werkte Google al samen met Code Intelligence om de Jazzer-fuzzingengine in OSS-Fuzz te integreren en zo projecten op basis van Java Virtual Machine-talen continu te kunnen monitoren.

Beide bedrijven passen die engine nu zo aan dat deze Java Naming and Directory Interface- of JNDI-look-ups die worden uitgevoerd kan detecteren. Dat soort look-ups kunnen leiden tot misbruik van kwetsbaarheden op afstand met mogelijk het uitvoeren van kwaadaardige code of het wegsluizen van data tot gevolg. Het beveiligingsteam richt zich op Log4j vanwege de kritieke kwetsbaarheid in de populaire logginglibrary die vorige week werd bekendgemaakt. Beveiligingsbedrijven sloegen groot alarm om deze Log4Shell-kwetsbaarheid.

Reacties (13)

[GertMenkel]

Google is zeer actief op het opsporen van veiligheidslekken in zowel closed source als open source software. Ze hebben een van de meestgebruikte fuzzers ter wereld geschreven en zijn ook zeer geïnvesteerd in de security van hun hele softwarestack, van Kubernetes tot de Go-compiler.

Vergeet niet dat Android van het Java-ecosysteem afhankelijk is, kwetsbaarheden als deze kunnen een serieuze impact hebben op hun omzet in de Play Store. Ze kunnen daar maar beter preventief in handelen natuurlijk.

Google was kwetsbaar voor log4j op twee plekken geloof ik gelezen te hebben, net als zo'n beetje ieder bedrijf dat de afgelopen tien jaar een Java-applicatie geschreven heeft. Ik geloof dat de kwetsbaarheid zat in De Google Armer WAF engine, maar ik weet de details niet meer zeker.

[Reactie gewijzigd door GertMenkel op 8 augustus 2024 20:48]

[Anonymoussaurus]

Yep, zie: https://cloud.google.com/...pache-log4j-vulnerability, maar dat gaat over het gebruik van hun WAF om Log4Shell te mitigeren.

[Reactie gewijzigd door Anonymoussaurus op 8 augustus 2024 20:48]

[amx]

Google's Threat Analysis Group is verantwoordelijk voor het beschermen van heel veel eindgebruikers. Het gaat verder dan hun eigen producten beveiligen, dus snap ook de redenering ze willen hun concurrenten zwart maken, maar de realiteit is dat een zeer groot aantal bugs serieus misbruikt had kunnen worden zonder de inspanningen van Google en dit team.

[Rob Coops]

Natuurlijk heeft Goolge er ook eigenbelang bij een veiliger web is een web waar meer mensen gebruik van willen maken. Ook gebruiken zij zonder enige twijfel zelf ook deze library dus ook wat dat betreft hebben ze er zelf ook plezier van als dit soort problemen niet meer voorkomen.

Maar dat neemt niet weg dat Google met hun eigen security teams en de vele tools die ze kosteloos beschikbaar stellen zeer veel doet op het gebied van security waar ze zelf weinig tot niets aan hebben (niet direct in ieder geval). Indirect is het nu eenmaal zo dat als om welke reden dan ook mensen of bedrijven massaal zouden besluiten dat het internet niet veilig genoeg is en ze het dus maar niet meer zouden gebruiken Google een heel erg groot probleem zou hebben.
Het bedrijf is een product van het internet en kan niet bestaan zonder dus natuurlijk is het voor het bedrijf van levensbelang dat het internet zo veilig mogelijk is en dat zo vele mogelijk mensen er gebruik van maken.
Alle projecten die Google uitvoert zijn gericht op het vergroten van de userbase dan wel het uitbreiden van de diensten voor de userbase. Een project als internet voor de wereld door middel van ballonnen of bijvoorbeeld het aanleggen van een eigen fiber to the home netwerk juist in gebieden waar internet niet of nauwelijks te krijgen is is niet alleen omdat Google graag de mensheid verder wil helpen (is een leuke bijkomstigheid goed voor de investeerders en zo) maar het zorgt er ook voor dat de userbase kan blijven groeien.

Ik zou me eerder af vragen wie dit soort dingen anders zou moeten doen? Als het niet een van de hyperscalers is wie heeft dan de resources om zo iets te schrijven beschikbaar te maken en te houden voor honderden zo niet duizenden projecten die constant miljarden regels code scannen opzoek naar eventuele fouten die misbruikt zouden kunnen worden?
Als het een kleiner bedrijf zou zijn dan zouden de kosten voor het hosten van de oplossing en het ontwikkelen van de nodige technologie simpel weg niet op te brengen zijn. Ook is het heel erg de vraag of kleinere bedrijven voldoende mensen met voldoende kennis in huis hebben en kunnen houden om dit soort software te schrijven en te blijven onderhouden voor vele jaren zo niet decennia...
Ik denk dat buiten de Amazon, Facebook, Google en Microsofts van deze planeet er weinig andere bedrijven zijn die zich de kosten en de moeite kunnen sparen om dit soort projecten op te zetten en te blijven draaien voor misschien wel altijd.

Het is leuk om te roepen ja maar Google doet dit niet geheel uit de goedheid van het hart maar de andere kant is wel dat niemand anders het doet. En het dus niet puur publiciteit is die Google hier mee hoopt te bereiken maar dat het ook echt iets bijdraagt aan de ontwikkeling van zeer veel projecten waar Google al dan niet zelf misschien ook gebruik van maakt.

[thahajemnireal]

*geen feit* denk het wel *einde geen feit*

Maar ja: beter samenwerken dan het wiel telkens opnieuw uitvinden. Zou het erger vinden als over een jaar of 2 naar buiten komt dat Google dit kan, maar niet deelt.

[Marve79]

Ah ja want Apple doet wel alles uit barmhartigheid

[elmuerte]

Ik zie dat Jazzer (de fuzzer voor Java) open source is (Apache-2.0): https://github.com/CodeIntelligenceTesting/jazzer
En hiermee dus ook de gebruiken zonder Google's OSS-Fuzz
Echt gebruiksvriendelijk is Jazzer nog niet echt: https://github.com/CodeIntelligenceTesting/jazzer#usage

[gimbal]

Op zich een goed initiatief, het meest schrikbarende van dit hele euvel is toch wel hoe lang het onder de radar heeft gevlogen ondanks dat het open source was. Ik kan alleen maar een aanname doen dat er menselijke redenen zijn geweest waarom log4j niet zo strict bekeken werd. "Het is maar een logging library", "Het is van Apache dus het zal wel goed zijn", etc. etc.

Want ik vind het ook heel begrijpelijk, wie verwacht er nou van een logging library dat het met redelijke eenvoud externe code kan uitvoeren! Ik wist niet eens dat het mogelijk was in JNDI lookups te laten doen. Ik heb maar 1 keer in de log4j documentatie gekeken ongeveer 15 jaar geleden ofzo, de eerste keer dat ik het moest gebruiken en individueel configurabel maken voor beide runtime en test classpaths. Daarna is het gewoon het kunstje herhalen.

[Nico de Vries]

Het helpt niet echt dat log4j uit ongeveer 200.000 regels code bestaat.

[markg85]

De echte fix: sloop elke vorm van resolving uit log4j!
Een logger moet loggen. Punt! Het moet niet "voor de handigheid" externe zaken kunnen resolven (ldap in dit geval). Het is vragen om problemen die je nu dan ook heb.