Voor het Java-platform leek 2013 wel een ‘annus horribilis’ wat security betreft. Want, als de Amerikaanse overheid adviseert om Java op je toestel te deactiveren, slik je toch even.

Die plotse aversie van Java wegens zwakke security, is des te opmerkelijker omdat het Java-platform steeds als bijzonder veilig werd aangeprezen. Het draait immers de Java bytecode op een Java virtuele machine (JVM), en dus zonder rechtstreekse toegang tot de onderliggende voorzieningen in het toestel, zoals geheugen, filesystem en dies meer. De JVM verifieert de werking van de code, en gaat code die niet van een gekende bron afkomstig is, of ‘untrusted’ is, in een ‘sandbox’ draaien. Zo kan bijvoorbeeld geen code kan worden geïnjecteerd in het werkgeheugen van het systeem, waardoor het crasht of de werking kan worden overgenomen voor boosaardige doeleinden. De Java security manager kan fijnmazig worden ingesteld betreffende welke code al dan niet naar de sandbox moet worden gestuurd.

Mooi, maar hoe verklaar je dan dat het nieuwe Java 8 met een stevige-vertraging zal uitkomen, om de security-aspecten ervan te verbeteren. Wat is er fout gegaan?

GEVAARLIJK PLUG-INS

Al die security-problemen hebben te maken met onveilige plug-ins voor browsers, waardoor malafide toepassingen op het systeem kunnen huis houden, aldus Oracle zelf. Die plug-ins laten toe om ‘untrusted’ code (code waarvan de goede werking en/of oorsprong niet verzekerd is) te draaien, die op zijn beurt de werking van het systeem verstoort. Toepassingen waarover men de volledige controle heeft, en die getest zijn, lijden niet onder het probleem, klinkt het.

Vandaag doen zwakheden opgeld in Java 6 en 7 (en nog 5), en dat zowel op Windows-, MacOS- en Linux-systemen. Begin dit jaar werden ‘zero day’ zwakheden in Java 7 aangewend door malafiden, terwijl ook nog toestellen werden getroffen door malware die misbruik maakte van gekende en reeds herstelde zwakheden…. maar waarvan de patches nog door veel gebruikers niet werden geïnstalleerd. Ook bedrijven als Twitter en Facebook meldden problemen met aanvallen die gebruik maakten van securityzwakten in Java. De toestand escaleerde dan ook met eerst vanwege experten, en vervolgens ook vanwege het Amerikaanse ministerie voor Homeland Security het advies om Java op je systeem uit te schakelen.

MEER DAN DE BROWSER

Maar er is nog meer aan de hand. Zo blijken de security manager en het sandbox-mechanisme niet altijd foutloos te zijn geïmplementeerd. En meteen ook een voorbeeld van een remmende voorsprong: andere platformen met een sandbox beschikken over modernere en meer robuuste implementaties, zodat de Java- omgeving een makkelijkere prooi vormt. Java is voorts op zeer groot aantal systemen aanwezig, wat zoals steeds de aandacht van misdadigers trekt. Vandaag kunnen ‘exploit packs’ worden aangeschaft, waarin verscheidene zwakheden samen worden aangewend (zoals het BlackHole-pakket, dat zwakheden in Java combineert met zwakten in onder meer Adobe Reader en Flash Player, aldus Kaspersky Lab).

Voorts zijn er ook problemen in de Java class libraries, waar onoordeelkundig gebruik ook voor onveilige software en dus misbruik kan zorgen. Een studie van Aspect Security uit 2012 leert dat 26 procent van de library downloads uit een populaire ‘repository’ gekende zwakheden bevatten (met onder meer GWT, Spring MVC en Struts 1. X als de meest gedownloade kwetsbare bibliotheken). Een verkeerde keuze van libraries kan stevige gevolgen hebben, aangezien tot 80 procent van de toepassingscode uit dergelijke libraries kan komen, aldus Aspect Security.

En het probleem dient zich ook aan op de Java native layer – de laag die het Java- platform in contact brengt met de onderliggende machine. In de voorbije periode is het aantal aanvallen op basis van zwakheden in die laag sterk gestegen, waardoor de security manager laag meteen wordt omzeild. Dat vereist wel meer kennis van de aanvallers, maar het maakt het de verdedigers ook moeilijker.

In zijn studie ‘Java every-days – exploiting software running on 3 billion devices’ schetst Brian Gorenc, manager vulnerability research bij HP’s Zero Day Initiative, een beeld hoe sinds 2011 meer dan 250 problemen werden gepatcht, waarvan 130 in 2013! En die problemen waren vaak ernstig, met meer dan de helft van de ernstigste voorbeelden in de eerste helft van dit jaar…

Kortom, Oracle heeft nog behoorlijk wat werk op de plank, en Mark Reinhold, chief architect van het Java platform, kondigde in april dan ook aan dat “Oracle [zich ertoe] verbindt door te gaan met het versneld oplossen van security-problemen, om het Java security model te verbeteren en om nieuwe security voorzieningen te introduceren. Dit zal meer uren werk vragen dan we kunnen vrijmaken door functies in Java 8 weg te laten, of in deze fase op een andere wijze de omvang van deze editie te verkleinen. Als gevolg van deze hernieuwde focus op security is de Java 8 planning, met een algemene beschikbaarheid begin september, niet meer haalbaar.” Momenteel wordt Java 8 SE verwacht tegen 18 maart 2014.

VERWAARLOOSD

Niet zelden werd er geklaagd dat Oracle het Java-platform heeft verwaarloosd wat security-problemen betreft. Niet dat er niets was gebeurd. De update-geschiedenis van Java SE 6 telt minstens 19 updates met security fixes, met in de eerste maanden van 2013 (tot april) een kleine honderd security fixes. Ook voor het nieuwere Java SE 7 (sinds 2011) werden al een 14-tal updates met security fixes uitgebracht, waaronder eentje in oktober van dit jaar, met 51 security fixes.

Oracle liet echter wel vaker de herstelling van gerapporteerde fouten lang aanslepen, en het communiceerde ook al te weinig over wat het deed. Het bedrijf heeft beloofd daar nu verandering in te brengen, zoals Milton Smith, Java security lead, stelt, “Het plan voor Java security is echt simpel: op nummer één staat het bijspijkeren van Java, en op nummer twee het in brede kring communiceren over onze inspanningen.”

WERK VOOR DERDEN

Ook de gebruikers zelf gaan niet vrijuit, door een gebrekkig update-gedrag. Hierdoor blijven systemen vaak veel langer dan nodig kwetsbaar voor aanvallen, ondanks de beschikbaarheid van patches. Vaak weten ze niet of Java op hun systeem actief is, laat staan welke versie en/of update het betreft. En vaak hebben ze ook niet de nodige systeemrechten om zelf die versie bij te werken. Bedrijven voorkomen zo de installatie van ongeoorloofde software, maar tevens dat een Java-update mogelijks bedrijfssoftware zou ‘breken’ die al te zeer op een specifieke Java-versie werd geënt (een klassiek probleem, ook buiten de Java-wereld).

Om bovenstaande redenen doen veel gebruikers nog een beroep op Java 6 (uit 2006), hoewel de publieke ondersteuning (inclusief security updates) daarvan in februari/april 2013 werd gestopt. “Dat een producent de ondersteuning stopt en geen security-herstellingen meer biedt, is niet nieuw. Het feit dat meer dan 50 % van de gebruikers nog steeds Java 6 draaien, maakt dit een toestand zonder voorgaande”, aldus Trend Micro’s Christopher Budd, threat communications manager: “Dit is een grote groep van kwetsbare gebruikers die nooit zullen beschermd worden met security-oplossingen en dus geschikte aanvalsdoelen vormen.” Hij meent voorts dat de vloed aan Java-aanvallen allicht deels kan worden verklaard door het security-beterschap in andere omgevingen, zodat Java het zwakkere boertje werd.

En last but not least moeten ontwikkelaars leren hoe veilige Java-software te schrijven. Die kennis ontbreekt bij nog teveel ontwikkelaars, en niet alleen in de Java-wereld (of ze nemen/krijgen er de tijd niet voor). Het verbaast dan ook niet dat op de recente JavaOne een Duke’s choice award werd toegekend aan Contrast Security Inc, een bedrijf dat een interactieve security testoplossing biedt voor Java EE toepassingen.

Guy Kindermans