Groot beveiligingsprobleem Java pas in februari gedicht

Een eind vorige maand ontdekt beveiligingsprobleem in Java, wordt pas in februari gepatcht. De bug zou te laat zijn gekomen voor Oracles driemaandelijkse patchronde. De kwetsbaarheid maakt het omzeilen van de sandbox mogelijk.

De vinder van het lek, de Poolse beveiligingsonderzoeker Adam Gowdiak, zegt tegenover Security.nl dat de kwetsbaarheid die hij ontdekte niet is meegenomen met een grote patch die dinsdag is uitgebracht. Daarin worden dertig kwetsbaarheden verholpen, maar niet die van Gowdiak.

Volgens de beveiligingsonderzoeker heeft Oracle hem gezegd dat de patch tijdens de eerstvolgende patchronde, in februari 2013, zal worden opgelost. Volgens Oracle kwam de melding van de kwetsbaarheid te laat binnen om deze mee te kunnen nemen tijdens de patchronde van deze maand.

De kwetsbaarheid die Gowdiak ontdekte, maakt het mogelijk om de sandbox te omzeilen en eigen code uit te voeren. Volgens de beveiligingsonderzoeker zijn een miljard Java-gebruikers kwetsbaar, omdat zowel de Java SE-versies 5, 6 als 7 kwetsbaar zijn.

Reacties (49)

[unglaublich]

Wat een bureaucratisch gemodder. Waarom kan Java niet eenvoudig op de achtergrond updaten zodat er wat vaker patchrondes gedaan kunnen worden?

[wildhagen]

Omdat je dat niet wil. Je loopt dan namelijk het risico, zeker in zakelijke omgevingen, dat bepaalde software niet meer werkt. Dat is namelijk nogal eens tricky bij Java-applicaties. En sommige applicaties vereisen zelfs expliciet een specifieke Java-versie.

Je krijgt nu al een update popup, dus de check zit er al in, maar een volledige unattended installatie lijkt me ook niet heel erg handig om bovengenoemde redenen.

[Fuzzillogic]

En een gekraakte PC is een niet veel groter ramp-scenario dat een bepaald stuk software dat mogelijk niet werkt en bijgewerkt moet worden?.. Pick your poison.

[f.v.b]

Pick your poison.

Een systeembeheerder bij een groot bedrijf is verantwoordelijk voor honderden systemen. Als je ongezien een update uitrolt en 10% van de medewerkers kan vervolgens niet meer aan het werk dan heb je een groot probleem.

Elke update zal dus onderzocht moeten worden. Wat is de kans dat er door de update iets kapot gaat en wat is de kans dat er door niet te updaten iets kapot gaat. De eerste kans kan je onderzoeken door een acceptatietest uit te voeren. En dat kost nu eenmaal tijd.

[ArcticWolf]

Bij ons wordt idd Java door de systeembeheerder beheerd. We kunnen het zelf niet updaten en maar gelukkig ook... anders werkt een deel van de applicaties opeens niet meer
Wordt de exploit al zovaak misbruikt dan?

[Mad-Monkey]

misschien nu nog niet, maar als een kwaadwillende weet dat hij iets kan maken wat maarliefst 3 maanden ongestoord zal kunnen werken.... Ik denk dat dit lek veel aandacht mag verwachten

[Golodh]

Is de vraag "Wordt de exploit al zovaak misbruikt dan?" relevant? Heeft het enige meerwaarde om te wachten tot het inderdaad vaak misbruikt wordt alvorens in actie te komen?

Behalve dan voor iemand die geen verantwoordelijkheid draagt voor toekomstige slachtoffers maar wel voor zijn eigen budgetje?

Of is hier sprake van een flinke dosis kortzichtigheid gekoppeld in een grote portie onverschilligheid, gelardeerd met een scheut eigenwijsheid?

[Tarkin]

sommige bedrijfskritische applicaties worden nu eenmaal niet verder ontwikkeld. Dan moet je wel. en kan je achtaf zeggen "I told you so"...

Wij werken hier ook nog met applicaties waarvan we in 2003 de testversie kregen (nog niet de volledige, daar waren ze te gierig voor) en dat we het er nu ook nog altijd mee moeten rooien. En dat is een systeem voor 4M klanten.

[arniejj]

Beveiligingsupdates zouden sowieso per major versie moeten worden uitgerold.. Dan gaat je compatibiliteitsissue niet meer op. Tenzij je software hebt dat 'rekening houdt' met de eventuele bugs in Java.

[JAVE]

Als Oracle Java update, dan gaat daar een een heel traject aan vooraf. Het is niet alleen maar dat ze eens per kwartaal een bestand naar buiten sturen...

Bug fixen, testen, build regressie tests.

En dat herhalen tot alle geplande dingen gedaan zijn. Dat proces stop je niet in een week (of twee, of drie)

[Verwijderd]

Nou als de halve wereld gehacked wordt, dan kun je het beter wel in een week stoppen (of liever, een dag). Nu disable ik Java altijd en overal gewoon (als browser plug in tenminste) omdat het gewoon onveilig is.

[JAVE]

Ik zeg niet dat het een goede beslissing is om dan maar 3 maanden te wachten, ik geef alleen maar aan dat ze niet 'gewoon even' vaker kunnen releasen.

Het probleem met Java is dat er zoveel gebruik van wordt gemaakt.. Je wilt dus niet een snelle fix maken die meer kapot maakt dan fixed.
Dit beveiligingslek is vervelend, maar het is niet iets van het niveau van een gat in Apache, of OpenSSH.

Je kan misbruik voorkomen door Java in browsers uit te zetten, en geen obscure java stuff te downloaden/runnen.

[LOTG]

Andere bedrijven kunnen dat blijkbaar wel in een paar dagen als er een kritisch lek is. Als er zo een groot probleem in je software zit, dan moet dat prioriteit krijgen.

En zo geweldig werkt dat hele proces blijkbaar niet, want dit is niet de eerste keer dat Java met dit soort lekken zit.

Wat er nu gebeurt is dat mensen Java gaan afraden, en ik heb het idee dat Java alleen nog maar in zakelijke software gebruikt word. Ik heb het al tijden niet meer geinstaleerd, en nog nooit gehad dat iets niet werkte daar door. En consumenten organisatisch raden ook al af om Java te draaien op je PC.

Oracle is Java gewoon kapot aan het maken

[moreasy]

Och, laten ze het nou eerst eens voor elkaar krijgen dat als ik Java instel om op woensdag om 15:00 te updaten, dat DAT DAN OOK ZO WERKT. En niet dat na het herstarten van de PC de update weer op de STANDAARD DAG : ZONDAG wordt ingesteld... (weliswaar om 15:00 maar dat terzijde)

Iemand die hier een oplossing voor heeft soms?
En kom niet aan met jucheck.exe beeindigen en javacpl als admin starten want dat werkt dus niet.
Ik wil iedereen oproepen om eens te proberen om de update op een andere dag dan zondag in te stellen, ik ben benieuwd.

[[Remmes]]

nou dan update je die toch eventjes een paar daagjes na de grote "patchronde"

wat is dat voor een kutmentaliteit om grote beveiligingsproblemen pas met patchrondes te dichten, vooral omdat die rondes dus blijkbaar 4 maanden duren

fix het, en update het, zo moeilijk is dat niet

[Reactie gewijzigd door [Remmes] op 2 augustus 2024 18:00]

[84hannes]

fix het, en update het, zo moeilijk is dat niet

Heb jij ooit softwarepaketten voor bedrijfskritische omgevingen onderhouden? Zonder het goed te willen praten als één miljard gebruikers kwetsbaar zijn (ik vind dat Proxy hierboven een punt heeft): zo moeilijk is het wel! Zie ook de reactie van JAVE. Ik durf niet uit te sluiten dat er zelfs bedrijven actief gebruik maken van het lek om hun applicaties taken uit te laten voeren die zonder dit lek heel omslachtig zouden zijn. Kwalijk? Zeker, maar kijk eens hoe verschillende browsers met dezelfde HTML-standaarden omgaan: slechts weinig programeurs volgen het boekje voor de volle 100%

[ArchLinux]

Eh... dus omdat er goedaardige applicaties zijn die gebruik maken van dit lek, moeten alle andere gebruikers, die alleen maar narigheid kunnen ondervinden van de kwetsbaarheid, van een veiligheidsupdate worden onthouden? Kom nou.

[laptopleon]

Dat zou inderdaad de omgekeerde wereld zijn. Soort van… 'Deze busdienstregeling klopt niet meer want nu moeten we ons aan de maximum snelheid gaan houden.'

[84hannes]

Er zijn een heleboel eisen die je aan een product moet stellen. Twee er van zijn "veiligheid" en "bruikbaarheid". Als je product niet bruikbaar is kun je het beter niet uitbrengen. Over onveilige producten kunnen we hele lange discussies houden dus daar zal ik geen uitspraak over doen. Ik volsta me het herhalen van bovenstaande stelling: als een product niet bruikbaar is kun je het beter niet uitbrengen.

[alienfruit]

Blijkbaar is de lek niet zo belangrijk dat ze het buiten de patchronde vrijgeven? Erg vreemd, ze zeggen dus dat het een 'groot beveiligingsprobleem' is. Maar ze nemen niet de moeite om het buiten de patchronde of deze ronde uit te stellen...

[Reactie gewijzigd door alienfruit op 2 augustus 2024 18:00]

[Proxy]

Dat bedoel ik, die onderzoeker maakt waarschijnlijk van een mug een olifant.

[paul999]

Of Oracle geeft gewoonweg niets aan veiligheid, en kan het niet schelen dat gebruikers 3 maanden lang onveilig software gebruiken. Klinkt als een iets realistischer scenario.

[Standeman]

Ik krijg steeds meer het idee dat Oracle er met de pet er naar gooit en de veiligheid van hun gebruikers geen bal intereseert. Ik draai in ieder geval geen java-plugin's meer in mijn browser, maar hoe reageren bedrijven er op waneer zij diensten voor medewerkers hebben draaien die hiervan gebruik maken?
Nu is java al een tijdje niet meer noodzakelijk (is het imo ook nooit geweest), maar als je nog diensten aanbied waar een java-plugin een vereiste is, kan je maar beter gaan denken om het met andere technologie op te lossen..

[Verwijderd]

draaide je uberhaupt al java applets?

laatste keer dat ik een java applet heb gebruikt is...... heel lang geleden

je kan nog prima een stuk software aanbieden die nog met een java applet werkt , de programmeur van het applet heeft simpelweg meer mogelijkheden en vrijheid dan die eigenlijk zou moeten hebben.

dus zolang de gebruiker niet domweg elke applicatie accepteerd zijn er totaal geen problemen. dus vandaar geen directe patch, domme mensen verdienen het gewoon om gehackt te worden...

[kmf]

Altijd goed om te weten welke prioriteit een bedrijf geeft aan veiligheid....

[Stephan Oudmaijer]

Ja Oracle zit er bovenop zoals je ziet :-)

Ik vind het als Java programmeur een blamage voor Java dat Oracle zo laks omgaat met dit soort zaken. Wat mij betreft is dit een signaal dat Oracle het product Java voor de desktop ook volledig links laat liggen en geen prioriteit geeft. Er is ook maar 1 echte optie en dat is om de Java plugin te disablen of de hele JRE te uninstallen.

Ze hadden sowieso wat meer vaart moeten zetten achter het modulair maken van Java (project jigsaw). Dan hadden ze ook beveiliging updates IMHO ook veel makkelijker kunnen uitrollen.

[Finraziel]

Ik moest gister toevallig bij een klant een nieuwe java versie installeren voor een probleem en daar viel het me al bij op dat je blijkbaar een account moet aanmaken bij Oracle en inloggen alleen al om een JRE te downloaden. Dat soort belachelijke dingen zeggen mij in feite al genoeg dat Oracle Java dood lijkt te willen. Juist het distribueren van de runtime moet je toch zo makkelijk mogelijk maken? Dan nog van die rare dingen als dat de automatische java updater om admin rechten vraagt vóórdat je de keuze krijgt of je de update wil installeren, nee gebruikersvriendelijkheid lijkt totaal geen aandacht te krijgen, sterker nog, het voelt als minachting voor de klant vanuit Oracle (al zou dit specifieke dingetje misschien best al uit de sun tijd kunnen stammen, weet ik niet).

Als je op dit moment java nog móet gebruiken dan zit je in een lastig parket inderdaad, maar door de algehele houding van Oracle zou ik toch zo snel mogelijk proberen om van die afhankelijkheid af te komen. Vond het ook wel typisch om bij de install nog zo trots de meldingen te zien over hoeveel apparaten java wel niet gebruiken, terwijl in mijn ervaring bijna overal java zo hard mogelijk overboord gegooid wordt. Iedereen probeert snel het zinkende schip te verlaten.

[Verwijderd]

Ik moest gister toevallig bij een klant een nieuwe java versie installeren voor een probleem en daar viel het me al bij op dat je blijkbaar een account moet aanmaken bij Oracle en inloggen alleen al om een JRE te downloaden.

Voor eindgebruikers is java zonder Oracle account te downloaden van java.com. Alleen voor pre-release versies en SDK's moet je een login hebben.

[gimbal]

Bla bla bla. Oracle heeft er absoluut geen baat bij dat Java 'dood gaat' aangezien een grote hap van hun eigen commerciele producten gebouwd is op dat platform.

Het heeft ook geen moer met Java te maken - waar men hier over valt is hun idiote policy met betrekking tot patch runs. Om de 3 maanden, hoe zot kun je het maken!

[Mikero]

Waarschijnlijk bedoelde je deze opmerking niet 100% serieus maar ik wilde toch even opmerken dat de overstap voor bedrijven groot of klein juist niet zo gemaakt is.

Sterker nog, sommige bedrijven kunnen het gewoon niet veroorloven om over de stappen op een nieuwe taal en hebben meestal al een arsenaal aan libraries en software pakketten. En natuurlijk het omscholen van personeel kost ook bakken met geld.

Maar ik hoop dat Oracle zeer binnenkort in gaat zien dat ze een beetje laks overkomen de laatste tijd en hier veranderingen in brengen. Java verdwijnen zal voorlopig niet gebeuren omdat er simpelweg gewoon geen vergelijkbaar alternatief is voor veel mensen (C# is van Microsoft, andere talen zijn niet populair genoeg e.d.).

[GamingZeUs]

C# lijkt enorm veel op Java en migratie zou heel makkelijk moeten zijn. Denk niet dat het voor de meeste Java bedrijfjes onhaalbaar is. Ik denk dat als je de code vertaalt je dat ongeveer zo snel doet als je kan typen, het kan bijna letterlijk over.

[Verwijderd]

Een overstap is helemaal niet zo makkelijk. Ok, C# lijkt goed op Java kwa syntax en een stuk ook de standaard meegeleverde libraries, maar daar stopt het dan ook. Al de rest is anders. Denk maar aan IoC frameworks, web frameworks, ORM libraries, ... Ik denk zelfs dat het voor de meeste projecten voordeliger zou zijn om een full rewrite te doen (uiteraard wel gebaseerd op de oude code) dan om puur de code te porten.

Ik ga er wel mee akkoord dat bedrijven die voornamelijk Java gebruiken kunnen overstappen naar .NET voor nieuwe projecten, maar dan is het de vraag als zij niet de helft van hun development team verliezen.

En ik negeer hier nog de OS issues.

[wvd_vegt]

Helaas hebben veel bedrijven inderdaad niet die luxe maar C# leeft een stuk meer dan Java de laatste jaren. Zoiets als een simple en foutloze File.ReadAll als in C# miste tot voorkort. Het concept van properties mist nog steeds.

Net zo laks als Oracle is met paches is het met nieuwe taal/library features. Als je zaken als Linq en Lambda expressies geproefd hebt en stukken Delphi & Java code van 50+ regels in 2-3 regels leesbaar kunt herschrijven moet je toch een lampje gaan branden.

Ik vraag mij nog steeds serieus af waarom ze Java niet gewoon afstoten.

[Verwijderd]

Ik vraag me af; Ik als gewone gebruiker, die vooral surft, utorrent gebruikt, en MPC-HT etc. En daarnaast een office 10 heeft draaien. Heeft zo'n gebruiker wel java nodig ?

Ik heb het gisteren gedeinstalleerd, en heb nog geen problemen gemerkt, maar heb nog niet alles uitgeprobeerd.

[MrSleeves]

Imho is Oracle gewoon een bedrijf waar je zover mogelijk vandaan wilt blijven.
Ik moet de eerste applicatie met een degelijke GUI nog zien. Het is altijd een drama. Ook v.w.b. Java word ik te vaak geconfronteerd met updates, en als ik dan de update installeer, werkt bv. Live Timing van F1.com niet meer (eigenlijk de enige reden dat het geïnstalleerd is)

En als je naar de mening van Brian Cantrill (ex-Sun, ex-Oracle) luistert, weet je waar Oracle's prioriteiten liggen (zelfs als er maar een deel van waar zou zijn, aangezien hij niet echt objectief is): http://www.quora.com/Whats-so-bad-about-Oracle

[Robtimus]

Java 7 update 5 is uit juni. Het is nu 4 maanden later en we zitten op Java 7 update 9 (eergisteren gereleased). Dat is dus gemiddeld 1 release per maand. Van die 3-maandelijkse cyclus kan dus wel degelijk worden afgeweken.

[gron74]

Sinds Sun in handen is gekomen van Oracle is het niet beter geworden. Je kunt je afvragen waarom Gosling weg is gegaan bij Oracle. Oracle is Amerikaans dus het beste is om Oracle voor de rechter te slepen voor iedere inbreuk die wordt gedaan. Helaas luisteren dit soort grote bedrijven alleen naar een rechter ipv de consument.

[joho]

Ik hoor wel iedereen over dat 3 maanden langzaam is, maar niemand over de voorwaarden voor deze exploit. Geen idee of dit door een foute webpagina te bezoeken kan worden uitgelokt, of dat je hiervoor een gesigned library of een root gebruikersaccount (lees Administrator rechten) nodig hebt.

Dat is het voordeel van de meeste linux distro's.
Als dit in OpenJDK word gefixt zal het binnenkort wel in de distributie opduiken.