De lekken die Java de laatste tijd plagen zitten in de client-side. Voor de meeste Java-ontwikkelaars heeft dat minder grote gevolgen dan het lijkt. Veel Java-ontwikkelomgevingen op de desktop, zoals Eclipse IDE, draaien niet eens in de SecurityManager. Die is beter bekend als de sandbox van Java die werd geïntroduceerd toen Sun de applets aan de man wilde brengen. Het programmaonderdeel is eigenlijk Java’s equivalent van bijvoorbeeld SELinux. Het bepaalt welke class in Java welke functie kan uitvoeren, zoals ‘risicovolle’ opdrachten als toegang krijgen tot het bestandsysteem. Een soortgelijke – maar minder verfijnde – functie krijg je bijvoorbeeld met de permissions in Unix.
De bedrijven en ontwikkelaars die worden geraakt door een lekkend Java zijn bijvoorbeeld de mensen die de Java-API Swing implementeren. Er zijn een paar grote applicaties die afhankelijk zijn van client-side Java. In deze categorie gebruik ik zelf alleen WebEx en daar houd ik een aparte browser voor aan die ik alleen maar heb voor WebEx. De Java-gaten leveren problemen op voor ontwikkelaars die met meerdere architecturen werken in één JVM. Maar de meeste daarvan zijn niet afhankelijk van een enkele JVM, maar gebruiken virtualisatie.
Twee jaar voor een fix? Nee hoor.
Volgens sommige beveiligingsdeskundigen duurt het twee jaar om de SecurityManager te repareren. Dit is niet helemaal waar. Het lek is al gepatcht. Wat ze bedoelen is dat de koppelingen van het programmaonderdeel dat Sun creëerde een zootje is. Het zal gerust twee jaar duren voor dit beveiligingssysteem volledig is herontworpen, maar twee jaar om de boel te repareren lijkt me onwaarschijnlijk.
Als een nieuwe SecurityManager bij een nieuwe release wordt geveegd (dat zal dan Java 8 zijn), dan hebben we het over twee jaar om de versie volledig uit te rollen. Deze zet zorgt er waarschijnlijk voor dat de meeste mensen die worden getroffen door het issue – zoals die ontwikkelaars die Swing gebruiken – niet meer compatibel zijn met eerdere versies. En dat geldt in veel gevallen voor applicaties die al verouderd waren bij het verschijnen van Java 7. Maar dat maakt vaak niet uit, omdat het dan meestal gaat om server-side programmatuur die de SecurityManager niet eens gebruikt.
Terug naar C? Nee hoor.
Java is over het geheel genomen nog altijd veiliger dan C. Dat klinkt als een absurde uitspraak, maar bedenk dat C gevoelig is voor buffer-overruns en –uderruns, terwijl Java dat in principe niet is vanwege de manier waarop geheugen wordt toegewezen. De meeste lekken waarin privileges verkeerd worden toegewezen hebben te maken met deze twee veelvoorkomende bugs.
Het voordeel van Java is juist dat het programmeurs een tool geeft om krachtige applicaties te bouwen zonder risicovolle taken als geheugenbeheer te gebruiken. De volgende generaties van geavanceerde computertalen probeert ontwikkelaars ook te behoeden voor dit soort beheer. Deze maatregelen worden vaak niet speciaal ingevoerd om applicaties veiliger te makken, maar ze hebben wel vaak grote gevolgen voor de beveiliging.
Onveilige clients? Nee hoor.
Java heeft een implementatie bij clients die niet dezelfde beveiligingsinfrastructuur heeft en erg succesvol is: Android. Dit OS is het begin en de toekomst voor client-side Java. De rest gebruikt toch AJAX/HTML. Wie maalt er dan verder om een Java-plug-in of client-side Java-app? Ik niet. Tijd om vooruit te denken!
Binnenkort horen we vast weer over het grootste lek bij interactieve elementen en dat blijft Flash. Schakel dat nu maar vast uit. YouTube leunt niet meer op Flash en stapt over op HTML5 bij browsers (Chrome en Firefox) dus je zult de opvolger van kuikentje piep niet hoeven missen. Eerlijk gezegd is Flash een groter en veel verder verspreid probleem dat veel meer tijd nodig heeft om uit te faseren. Onthoud gewoon het volgende: wanneer het gaat om beveiliging zijn plug-ins voor de browser een slecht idee.
-
-
Er zijn nog geen reacties.Reageer
Preview