'Veelgebruikte opensource-Java-libraries vertonen kwetsbaarheden'

Volgens een onderzoek van Aspect Security vormt meer dan een vijfde van de opensource-Java-libraries een beveiligingsrisico. Door het brede gebruik van sommige libraries zou elk programma minstens één bekend beveiligingsgat hebben.

Beveiligingsbedrijf Aspect Security en softwarebedrijf Sonatype hebben de 31 populairste Java frameworks en beveiligingslibraries van 'the Central Repository' getest. In het onderzoek kwam aan het licht dat 26 procent van de onderzochte libraries kwetsbaarheden bevat. Dat zou betekenen dat de meeste Java-programma's een kwetsbaarheid bevatten door het gebruik van dergelijke libraries.

De meest kwetsbare libraries zijn volgens het onderzoek GWT, Xerces, Spring MVC en Struts. De onderzoekers menen dat de helft van 's werelds grootste bedrijven dergelijke libraries gebruikt en dus ook getroffen kan worden door een kwetsbaarheid in deze Java-bibliotheken.

Het gebruik van libraries is populair onder programmeurs. Bepaalde veelgebruikte functies hoeven dan niet telkens opnieuw geschreven worden, maar kunnen van websites worden geplukt om in een programma te worden geïntegreerd. De twee onderzoekers manen aan om ook die code beter te debuggen en te controleren op beveiligingsproblemen.

Reacties (66)

[Rob Coops]

Nee joh... wie had dat nu gedacht. Men weet al jaren dat Spring, GWT en zo veel andere libraries fouten bevatten maar over het algemeen bevatten ze minder fouten dan de hoeveelheid fouten die er in een eigen ontwikkeld framework zou zitten. Dus als ik moet kiezen dan is hoe dan ook een bestaande goed geteste en zeker werkende library beter dan zelf het wiel uitvinden. Daar naast wordt er nog iedere dag an de verschillende framworks ge werkt om de functies maar ook de beveiliging te verbeteren iets dat je niet echt kunt doen als je een eigen framework bouwt simpel we omdat je daar het geld en de tijd niet voor hebt.

Dat het niet handig is dat er fouten in zitten is een ander verhaal en dat men beter op zou moten letten en niet blind moet vertrouwen op de libraries is geheel waar. Maar de meeste bedrijven zullen het argument gebruiken dat ze hun ontwikkelaars liever aan voor hun nuttige code laten werken dan laten werken aan het verbeteren van de frameworks waar deze code opgebouwd is.
Natuurlijk als een developer een fout vind en een patch aandraagt zullen de meeste bedrijven geen probleem hebben hier mee maar als een developer voornamelijk patches voor de framework schrijft en dus voor het bedrijf weinig productief is zal dit niet echt gewaardeerd worden.

Het geen ik vreemd vind is dat deze onderzoekers blijkbaar simpel weg fouten zien maar er althans voor zo ver duidelijk wordt uit de tekst verder niets mee doen. Het had toch leuk geweest als men de moeite had genomen deze fouten aan de developers achter de frameworks door te geven om deze ook opgelost te krijgen. wat dat betreft lijkt het er erg op dat de onderzoekers zelf niet veel beter werk hebben geleverd dan de developers die ze op hun fouten wijzen.

[RSpliet]

Jawel, In libraries zitten inderdaad minder fouten, en omdat het absoluut gezien minder fouten zijn is het efficienter. Het probleem met libraries is echter dat de fouten grotere consequenties hebben. Wellicht dat het volgende voorbeeld meer tot de verbeelding spreekt: als Google Chrome een beveiligingsgat bevat, dan is Google Chrome lek. Bevat WebKit een lek, dan is Chrome, Safari, Epiphany, iOS, Android en WebOS onveilig. just to name a few. Libraries zijn weliswaar veiliger, maar de consequenties van een bug erin groter. Niet te vergeten dat deze libraries ook een waarschijnlijkere target worden voor hackers omdat ze op zoveel plaatsen gebruikt worden.

[majoh]

Kan niets anders zeggen dat jij de essentie helemaal goed hebt.

Beetje vreemd onderzoek, zoeken naar bekendheid. Alsof niet open-source code geen bugs zou hebben...

[SunnieNL]

De kracht van open source was toch dat anderen die van die gaten afweten, zelf die gaten kunnen dichten en weer aan de community terug kunnen geven?

Of is het meer een community van 'ignore en we zien wel waar het script strand' geworden?

[Katsunami]

Zelf gebruik ik ook veel open-source software. Ik lever mijn bijdrage via bugreports en programmeer niet zelf, hoewel ik wel kan ontwerpen en programmeren. De reden is simpel: ik ben een Embedded Software Engineer, en ik schrijf dus algoritmen, programma's en dergelijke voor apparatuur. Hoewel ik probeer om die zo veilig mogelijk te maken (buffer-overruns voorkomen, etc) heb ik weinig verstand van desktopsoftware en al helemaal geen van Java-libraries.

Ik denk dat het voor het overgrote deel van de mensen die OSS gebruiken vergelijkbaar is.

[magistus]

Die kracht is niet meer/minder doordat er fouten gevonden worden. Fouten zijn en blijven, het is en blijft mensenwerk. Open source/Free software heeft, ten opzichte van proprietary software, wel het voordeel dat fixes a) door externen aangeleverd en gepatched kunnen worden, b) bij geen reactie van de leverancier, geforked kunnen worden en c) je deze indien echt noodzakelijk zelf kunt patchen. Links- of rechtsom, er is geen enkele code meer betrouwbaar dan goed doorgekauwde open source software, de vraag is alleen hoeveel volk zijn tanden er in wil zetten.

[ATS]

Je hebt helemaal gelijk. Library code die wijd gebruikt wordt, heeft meestal minder fouten dan zelfontwikkelde frameworks. Maar het probleem is, dat die fouten - en daarmee kwetsbaarheden - wel hetzelfde zijn voor elke applicatie die die libraries gebruikt! Dat maakt dat de impact van die fouten des te groter is, omdat een grote range aan applicaties kwetsbaar blijkt voor dezelfde aanval. Een aanval opzetten tegen een enkele applicatie gebouwd met een zelf-ontwikkeld framework is wellicht niet zo interessant voor de meeste programma's en de meeste doeleinden, maar dat ligt anders als eenzelfde issue grote groepen applicaties treft.

[Pep7777]

Libraries gebruik je als ontwikkelaar al heel snel. Zelfs een simpele routine om tekst op het scherm te zetten ga je niet zelf zitten typen. (nou ja zo simpel zijn ze tegenwoordig met grafische systemen ook al niet meer).
Laat staan als je iets meer wilt doen dan dat, je gaat toch niet iedere keer het wiel opnieuw uitvinden.

Hoe dan ook wat mij betreft hangt de kwetsbaarheid van een library ook af van hoe en waar je hem gebruikt. Als je de library in een off-line systeem of in een systeem waar de library niet (in)direct aan het internet hangt dan is beveiliging niet zo heel belangrijk.

Dus wat dat betreft zegt deze test mij in eerste instantie niet zoveel. Is zoiets als gaan klagen dat een gewone fiets kapot gaat als je ermee gaat mountainbiken.

Maar als ontwikkelaar (ja ik ben er zelf ook 1) vind ik het wel belangrijk dat ik en mijn collegas professioneel te werk gaan. (En niet te snel tevreden zijn met, goh het lijkt te werken dus ik ben klaar).

Het blijft het als ontwikkelaar van een library altijd belangrijk NOOIT te vertrouwen op de input van de ontwikkelaar die je library gebruikt. En dubbel-check je eigen aannames, of beter gezegd check of je niet ergens aanames gemaakt heb (van het zal wel goed komen) en voeg controles toe!

[YopY]

Het gebruik van libraries is populair onder programmeurs.

Pardon? Deze zin is verwoord alsof het voor de leukigheid is dat er libraries gebruikt worden, maar sorry hoor, libraries zijn keihard onderdeel van het vak, je kunt niet anders, of je moet je eigen OS van de grond af opbouwen (tot op het laagste niveau).

Over wat voor kwetsbaarheden hebben we het hier uberhaupt?

[Donderwolk]

Goede vraag, kwetsbaarheden in de code of mogelijke kwetsbaarheden door gebruik van het framework? Zie bijv ook: http://www.springsource.com/security/spring-mvc voor een aantal kwetsbaarheden die voort komen uit het gebruik van het framework maar niet per se kwetsbaarheden in de code zijn.

[LOTG]

De twee onderzoekers manen aan om ook die code beter te debuggen en te controleren op beveiligingsproblemen.

De reden dat je zo'n library gebruikt is juist om tijd te besparen. Ik denk dan ook niet dat veel developers zitten te wachten op het debuggen van complexe code in externe libraries.

Dit is toch een grote klap voor JAVA developers. Zij zullen er straks op aan gekeken worden dat er onveilige software geleverd is, wat natuurlijk niet eerlijk is.

Ik neem aan dat de makers geinformeerd zijn en we snel een fix kunnen verwachten?

[Dreamvoid]

"de makers" is de open source community zelf. Deze libraries fixen zichzelf niet, zonder bijdrage van bedrijven of vrijwilligers verandert er geen regel code.

[Oerdond3r]

Open-source libraries worden meestal door vrijwilligers of bedrijven beheert. Hier kun je de security lekken naartoe sturen en dan lossen ze het op. Mocht een open-source project niet meer beheert worden en verlaten zijn, dan is het common practice om dit project ook niet te gebruiken voor je applicatie.

[Dreamvoid]

Hier kun je de security lekken naartoe sturen en dan lossen ze het op.

Dat open source project heeft alleen geen kelder vol magische bugfixende kabouters, daarvoor zijn ze afhankelijk van vrijwilligers. Ofwel ze vragen een corporate sponsor om de bugs te fixen, ofwel individuele vrijwilligers gaan aan de slag.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 14:58]

[The Van]

Natuurlijk is dat wel "eerlijk": wel eens van testen gehoord?!?

[CodeCaster]

Wat moet er getest worden dan, en door wie?

[Anoniem: 167912]

het komt me voor dat deze massaal gebruikte libraries veel uitgebreider getest zijn dan code die van nul af aan wordt geschreven.

[robinverl]

Onder het mom: elk nadeel heeft zijn voordeel. Als vele mensen een library gebruiken met een fout, dan zijn er ook vele mensen beschikbaar die de betreffende fout mogelijk kunnen vinden en oplossen. Kortom, laten we hopen dat snel de meeste bugs worden gefixt

[Anoniem: 80466]

Zelfs als de bugs gefixed zijn in nieuwere library versies zullen de programma toch nog kwetsbaar blijven.

[robinverl]

Lijkt me toch dat een fatsoenlijk bedrijf ook patches en updates zal uitbrengen op bestaande software, waarna die kwetsbaarheden dus verdwijnen.

[DeuTeRiuM]

Tenzij libraries system wide geinstalleerd zijn.

[Anoniem: 452494]

Wow, dit wist ik niet dat zoveel libs geen goede beveiliging heeft. Sommige van mijn klasgenoten die werkte ook met Spring voor een Java project. Ik vraag me af wat je allemaal kan doen via deze beveiligingsgaten en hoe je het kan oplossen, want veel libs zijn wel handig en ik kan niet bepaald een hele lib anders schrijven.

[deadeyes]

Ja idd.

Alles zelf schrijven is eigenlijk uitgesloten. En dat is voornamellijk omdat we niet over oneindig veel tijd beschikbaar hebben.

Het is niet omdat je klasgenoten dit gebruiken je er ook iets mis mee kan doen.

Ik stel voor dat je zelf eens op onderzoek gaat.
Je hebt waarschijnlijk de source code beschikbaar (dat zal het al serieus gemakkelijker maken). Dus kijk welke versies van welke libraries. Ga op zoek naar exploits/poc/...
en probeer het eens uit...

Je moet er rekening mee houden dat de gebruiker ook kennis van zaken nodig heeft om dit te doen.
Dus zodra je in een bedrijf zit van enkele 100 man heb je waarschijnlijk 0 personen die deze code kunnen exploiten.
Hoe meer exposed je applicatie is, hoe meer kans dat er vroeg of laat eens iemand hier misbruik van maakt.

[Pineka]

Je moet Java natuurlijk wel op tijd updaten. Dat zag je laatst maar weer met die hack op nu.nl. Of beter nog, installeer geen Java.

[majoh]

Java en Javascript, zoals op nu.nl, is totaal iets anders...

Daarnaast hebben we het hier vooral over serverside code niet over de Java plugin van de browser.

[LOTG]

Ik weet niet wat je nu wilt zeggen, maar de exploit targette weldegelijk Java en niet JavaScript. Je was dus ook vatbaar als je een verouderde JVM gebruikte.

En wat bedoel je met server side code? Het gaat hier om libraries die ook door Java applicaties op je thuis PC gebruikt kunnen worden, niet alleen de server side stuff.

[Dreamvoid]

Er zijn alleen anno 2012 niet zo heel veel client-side Java applicaties (meer), terwijl zo ongeveer het hele web op server-side Java libraries draait.

[pibara]

Uhm, andersom bedoel je. M'n telefoon draait volgens mij alleen maak client side java apps, terwijl JavaScript (Node.js) en C++ (boost::asio) de server-side aan het terug pakken zijn omdat Java het met de connectieaantallen van 2012 vaak niet meer trekt.

[seppevs]

Spring MVC, wat in het artikel als voorbeeld wordt gegeven, is server side Java technologie. De versie van de JVM heeft daar niets mee te maken.

[jj71]

De hack op nu.nl heeft helemaal niets met Java te maken. (JavaScript heeft niets met Java te maken).

Afgezien daarvan heeft het updaten van je Java runtime environment heeft helemaal niets te maken met waar dit artikel over gaat. Het gaat over open source libraries van derde partijen die door heel veel Java ontwikkelaars worden gebruikt. Deze libraries zijn geen onderdeel van de standaard Java runtime.

[CodeCaster]

Het standaardgrapje "Java != Javascript" als het over websites gaat, gaat hier niet op.

De stelling klopt natuurlijk wel, maar de rootkit die via nu.nl is verspreid, werd wel degelijk op je systeem geplaatst middels een Java-exploit.

[jessy100]

voor sommige dingen ben je verplicht java te gebruiken. dit is weel heel makkelijk gezegd.

[Anoniem: 441072]

Een kwetsbaarheid komt pas aan het licht als er ook misbruik van wordt gemaakt. Het is daarom goed voor alle ontwikkelaars die iets vreemds vinden in de sources, dat gauw meldt aan de ontwikkelaars van de libraries.

Ik gebruik ook libs van derden en ik moet eerlijk zeggen, ik ga echt niet zoeken naar kwetsbaarheden van de libs. Het is downloaden, functies aanroepen, kijken of gewenste resultaten verkregen worden en klaar (dat staat natuurlijk los van delen door nul, try/catch in enz... in eigen code).

[zvbhvb]

Die 26% is dat een aanname of extrapolatie of heeft men ze geteld door een source code audit?

Want in het laatste geval zou je toch het hele gebeuren kunnen patchen?

[Jegorex]

Ik denk dat dit niet alleen het geval is met Java libraries. Als je dit onderzoek doet voor andere talen zul je daar waarschijnlijk ook genoeg libraries vinden die lek zijn.