Onderzoeker ontdekt groot beveiligingsprobleem in Java

Een beveiligingsonderzoeker heeft een ernstige en nog ongepatchte bug in Java ontdekt. In Java SE 5, 6 en 7 zou het mogelijk zijn om de sandbox te omzeilen en eigen code uit te voeren. Een miljard Java-gebruikers zou kwetsbaar zijn.

Volgens beveiligingsonderzoeker Adam Gowdiak is het mogelijk om gebruikers op volledig gepatchte Windows-systemen met Java SE 5, 6 of 7 aan te vallen. Dat schrijft hij op de Full Disclosure-mailinglijst. Alle grote browsers zouden kwetsbaar zijn, hoewel Gowdiak enkel rept van geslaagde tests in een 32bit-omgeving. Het is onduidelijk of ook 64bit-installaties kwetsbaar zijn, maar volgens Gowdiak zou een miljard gebruikers gevaar lopen.

Gowdiak doet niet uit de doeken hoe het beveiligingsprobleem precies werkt, maar meldt wel dat het mogelijk is om de sandbox-omgeving te omzeilen en dat het dus mogelijk is om eigen code uit te voeren. De onderzoeker heeft zijn onderzoek aan Oracle overhandigd zodat het lek gedicht kan worden.

De aankondiging van het beveiligingsprobleem komt op een pijnlijk moment voor Oracle: twee van de belangrijkste Oracle-bijeenkomsten, OpenWorld en JavaOne, gaan zondag van start. Bovendien is dit het zoveelste Java-beveiligingsprobleem in korte tijd. Zo bleek eind vorige maand dat Java 7 een ongepatcht en actief misbruikt lek bevatte, en de patch die dat probleem moest verhelpen, bevatte een nieuw lek.

Tegenover Security.nl zegt Gowdiak dat dit inmiddels het vijftigste lek is dat hij in Java heeft gevonden. De nu ontdekte bug zou de grootste tot nu toe zijn. Twintig van de door hem ontdekte lekken zouden nog altijd niet zijn gepatcht.

Reacties (110)

Volgens mij hoeft in de praktijk een groot aantal mensen zich amper druk te maken om dit beveiligingslek. Ik haal niet direct uit de aankondiging waar het lek zich precies bevindt, maar gezien het feit dat het met Windows en dus met clients heeft te maken, gaat het waarschijnlijk om lokale uitgevoerde Java-toepassingen die bijv. in Swing/AWT geshreven zijn en/of als applets draaien bijvoorbeeld. De groep mensen die dat draait is potentieel misschien miljarden, maar in de praktijk denk ik dat het er een stuk minder zijn. En dan nog zijn het vaak interne toepassingen, dus je moet moedwillig naar een site gaan die de bewuste Java-code bij jou lokaal wil gaan draaien.

Aangezien de meeste Java-technologie tegenwoordig aan de serverkant draait wordt het al een stuk moeilijker zoniet onmogelijk om als gebruiker de server-Java-code te 'hacken'. Java aan de client-kant in de vorm van applets/Swing is al lang niet meer waar Java het van moet hebben en ze zich ook minder druk om maken (misschien ook daarom dit veiligheidslek?), maar de server-wereld i.c.m. Java is nog altijd heel erg groot.

Ben dan ook benieuwd wat voor lek het nou precies is.

[Reactie gewijzigd door Tjeerd op 26 september 2012 12:27]

Zoals iemand anders al aanstipt en jij eigenlijk heel goed verwoord, is er een groot verschil tussen de Java browser plugin, Java client applicaties en Java als ontwikkeltaal en runtime in het algemeen.

Dat er een lek zit in de plugin of client applicatie code vind ik persoonlijk best belangrijk. Ookal gebruiken weinig sites het tegenwoordig nog en zijn er weinig client apps in gebruik die java gebruikt. Bijna elke pc heeft deze plugin en de Java runtime wel draaien...

Maar dat mag in de berichtgeving wel duidelijker aangeven worden. Aangezien Android, Java servers enz. niets te maken hebben met dit lek. En het dus niet een "groot beveiligingsprobleem in Java" is, maar een "groot beveiligingsprobleem in specifieke Java apps en/of browser plugin".

[Reactie gewijzigd door majoh op 26 september 2012 13:06]

Dat dit in het kader van het artikel als Informatief gemareerd is snap ik absoluut niet. De exploit is namelijk juist op de desktop gevaarlijk. Het is een exploit van de browser-plugin voor Java en die staat bij iedereen die Java installeert op zijn/haar systeem zonder te weten wat het nu precies is. (Die zijn meestal niet voldoende technisch onderlegd om de Java-plugin in hun browsers uit te zetten)

Ik haal niet direct uit de aankondiging waar het lek zich precies bevindt, maar gezien het feit dat het met Windows en dus met clients heeft te maken, gaat het waarschijnlijk om lokale uitgevoerde Java-toepassingen die bijv. in Swing/AWT geshreven zijn en/of als applets draaien bijvoorbeeld.

Begrijpend lezen van de aankondiging leert dat het hier gaat om een exploit die uit de sandbox voor de Java-plugin van de browser weet te ontsnappen. Anders zouden ze namelijk over de environment niet posten:

All tests were successfully conducted in the environment of a
fully patched Windows 7 32-bit system and with the following
web browser applications:
- Firefox 15.0.1
- Google Chrome 21.0.1180.89
- Internet Explorer 9.0.8112.16421 (update 9.0.10)
- Opera 12.02 (build 1578)
- Safari 5.1.7 (7534.57.2)

Mja, attack vector verplaatst overduidelijk ...
Windows blijkt toch steeds wat veiliger en lastiger te misbruiken, dus de aandacht verplaatst zich naar overige software als Adobe, Flash & Java

Dat en het feit dat Java en Flash (even als de meeste andere Adobe producten) simpel weg nooit echt aan beveiliging hebben hoeven doen. Je ziet het nu ook met MacOS, Android en iOS. Op het moment dat het spul niet alleen gebruikt wordt door miljoenen mensen is het op eens interessant om aan te vallen en blijken er vele bugs in te zitten... Dat is nu eenmaal de manier waarop dit soort dingen werken, alle software die geschreven wordt bevat bugs en beveiligings gaten maar tot dat het interessant genoeg is om het aan te vallen valt het gevaar dat dit soort gaten opleveren heel erg mee.

Oracle zal echt veel meer moeten doen aan het beter beveiligen van Java, als ze dat niet doen dan kon het nog wel eens het einde betekenen van de grootschalige toepassing van de Oracle VM simpel weg omdat het ding niet veilig genoeg is. Adobe is een stel prutsers en ze hebben in de vele jaren dat Flash vol op gebruikt werd nooit echt gaten in de beveiliging op gelost dus dat zullen ze waarschijnlijk ook nooit gaan doen. Dat is dan ook een van de vele redenen waarom de mobiele OS'en het al niet meer ondersteunen en de rest van het internet het ook steeds vaker laat vallen.

Dat en het feit dat Java [..] simpel weg nooit echt aan beveiliging hebben hoeven doen.

Pardon? Java (/JRE) heeft sinds het begin al veel aandacht bevestigd aan beveiliging. Dat die functionaliteit hier en daar wat fouten heeft, en zelden gebruikt wordt betekend het niet dat er geen aandacht aan besteed is.

http://docs.oracle.com/ja...security/PolicyFiles.html
Het is een heel krachtig systeem, maar nogal complex en gebruiks onvriendelijk. Resultaat dat het standaard volledig open staat. Ze zouden dit kunnen verbeteren en meer granulariteit kunnen bieden. Nu is het een beetje "all or nothing" voor applets, en "all" voor normale Java applicaties.

Nee hoor, dit is een onderzoeker die het lek gevonden heeft, geen criminelen die nu plotseling lekken in java gaan zoeken omdat Ms zo ontzettend veilig is.Trouwens, Ms heeft in allerijl een ernstig lek in Ie moeten dichten vorige week, hoezo veilig?Veiliger misschien

[Reactie gewijzigd door blobber op 26 september 2012 11:16]

Het vorige "major security issue" is anders ook nog steeds niet opgelost. Bij de laatste update van Java werd op verschillende sites (waaronder Tweakers) aanbevolen om Java geheel te verwijderen indien je dit niet persé nodig hebt.

Ik heb nog nergens een bericht gelezen dat dit ondertussen was gepatched. Dat dit nieuwe grote beveiligingsprobleem daar nog eens bovenop komt maakt het er allemaal niet beter op...

Java is altijd al een veiligheidsprobleem geweest. Het lijkt de laatste jaren enkel toe te nemen. Erg zorgelijk, deze ontwikkeling.

Vergeet het vorige lek...

Twintig van de door hem ontdekte lekken zouden nog altijd niet zijn gepatcht.

WTF??

[Reactie gewijzigd door freaky op 26 september 2012 12:12]

Als dat lekken zijn waarmee je als kwaadwillende weinig kunt, is dat natuurlijk ook geen hele grote ramp.

En jij verschiet??? Kijk naar je eigen pc alsof die standaard vol met lekken zit en hou daar rekening mee in gebruik...

Men is over het algemeen niet zo blij dat je een lek ontdekt, het geeft ze alleen maar meer werk om dat gat te dichten. Plus de slechte naam die het bedrijf in kwestie krijgt.

En java komt hier wel vaak voorbij met lekken.

[Reactie gewijzigd door BlaDeKke op 26 september 2012 12:23]

Plus de slechte naam die het bedrijf in kwestie krijgt.

Als het lek niet gedicht wordt, ja... Als Oracle al die lekken zou verhelpen, dan petje af juist. Goed bezig. Maar als ze weten van lekken én ze ongemoeid laten, dát is wat voor een slechte naam zorgt.

Ik verschiet ja. _Thanatos_ legt het al grotendeels uit. Low-level programmeren, waarbij je zelf memory allocate is gewoon lastig (en er komt veel meer bij kijken uiteraard). Dat je daarbij fouten maakt is begrijpelijk. Dat je er vervolgens willens en wetens geen hol aan doet is dat echter niet.

Wat mij betreft mogen ze aansprakelijk gesteld worden voor deze laksheid. Ben nooit blij geweest met de overname van Sun door Oracle. Nou valt het te bezien of Sun al van de lekken wist, maar heb sterk de indruk dat het daar veel beter was.

Nee hoor, dit is een onderzoeker die het lek gevonden heeft, geen criminelen die nu plotseling lekken in java gaan zoeken omdat Ms zo ontzettend veilig is.Trouwens, Ms heeft in allerijl een ernstig lek in Ie moeten dichten vorige week, hoezo veilig?Veiliger misschien

Crminelen maken ook gebruik van die lekken. Waarschijnlijk wisten zij ook al van dat lek, en mogelijk andere lekken in Java die nog niet gepatched zijn.

Trouwens, Ms heeft in allerijl een ernstig lek in Ie moeten dichten vorige week, hoezo veilig?Veiliger misschien

Jive zegt toch nergens iets over veilig? Hij heeft het enkel over veiliger en lastiger

Ik ook aan het eind

Niks is veilig, het kan veiliger en veiligst gaat gewoon niet. Webkit op iOS heeft een bug waarmee je bestanden/contacten/etc kan doorsturen naar de server van de kwaadwillende, toch nog enkele graadjes erger dan IE (die dezelfde week nog werd gepatcht).

Is dat niet zo met alle systemen? Het systeem is zo sterk als de zwakste schakel. Kijk naar iOS 6 via Safari pas geleden.

Ben bang dat nieuws: Eerste versie 'virtualisatie-OS' Qubes ziet daglicht de toekomst heeft. Alles gesandboxed (voor zover de applicatie dat zelf doet) in een eigen sandbox. Opzich ben ik het daar niet mee eens, maar het blijkt maar eens en temeer wel uitkomst te bieden.

Alles gesandboxed

En wat denk je dat de JVM, Flash en Adobe Reader zijn? Het zijn sandboxes die een specifieke 'systeem' taal kunnen uitvoeren. Hoeveel lagen van sandboxing wil je introduceren?

Wat dat betreft is het OS zelf ook een sandbox, in dat bijv een applicatie niet eventjes je bootschijf kan overschrijven met 1024 nullen aan het begin, of eventjes je BIOS wissen. Wat dat betreft is de controller van je harddisk ook een sandbox, in dat het BIOS niet kan besluiten de schijf op te voeren naar 25000rpm.

Het is maar hoe je het bekijkt. Er zit denk ik wel een technisch aantoonbaar verschil tussen een sandbox en een hypervisor...

Het blijft een oneindige wedstrijd. We breken ook wel weer uit die Qube. Val de hyporvisor aan en je gaat ook nat. Tuurlijk, zeer moeilijk en ik zou mijn God niet weten hoe. Maar het internet zit vol met knappe koppen die daar ongetwijfeld achter zullen komen. En dan komt er een patch.... en dan... etcetera

Wat maakt dat veiliger dan de VM van Oracle? Zelfde problemen kunnen optreden, de VM zelf heeft namelijk alle toegang, dus als jij die gaat aanvallen vanuit je virtuele omgeving kom je op het zelfde probleem uit.

Een echt probleem is sandboxing overigens niet, als de gebruiker toegang moet geven tot locale resource kan dat best goed werken. Waarom zou je browser bijvoorbeeld continu toegang moeten hebben tot je hele systeem? Die kan best af met een sandbox, en dan netjes vragen als de gebruiker iets buiten de sandbox wil opslaan.

En zo heel veel veiliger is het ook niet

Tsja wie heeft serieus nog Java ingeschakeld staan in zn browser? Is echt niet meer van deze tijd. Ik gebruik wel Java voor andere applicaties en voor ontwikkeling, maar in de browser staat die gewoon mooi uit. Als ik op een site kom met een Java applet, heeft die site gewoon pech.

Precies. Java wordt heel veel gebruikt, maar toch niet meer voor applets? Dat de JVM lek is, is storend natuurlijk en het moet verholpen worden, maar via een browser kan iemand dus zonder controle code uitvoeren in jouw JVM, en dat is hoe dan ook eng (Flash heeft in principe hezelfde probleem).

Gelukkig kun je die browser-plugins gewoon uitzetten, en wat mij betreft zou dat standaard ook gewoon uit moeten staan.

Iedereen die het niet uit zet? Zolang het nog standaard aanstaat zal het een probleem blijven. Niet iedereen heeft de kennis af te wegen welke software de browser gebruikt/nodig is voor een website laat staan dat je van mensen kan verwachten dat ze die afweging maken.

Java kan prima....zonder al die gaten.

Chrome komt altijd netjes vragen of ik Java wil inschakelen voor een site die de Java runtime nodig heeft.
Voor de website van mijn bank kan ik dan weer aangeven dat ik Java altijd toelaat.

Als je aan het rondsurfen bent, en Chrome komt vragen of je Java wil inschakelen kan je natuurlijk maar beter twee keer nadenken.

Ja makkelijker gezegd dan gedaan. het bedrijf waar ik voor werk gebruikt een bank applicatie van de ING die java nodig heeft.

Ik word er echt krankjorum van elke week weer een update (een update die alleen installeert als je als admin ingelogd bent, dus niet eens als admin onder de normale gebruikers account)

Java is echt de allergrootste bloated gatenkaas.

Ik ga volledig akkoord. Ik heb java nodig voor eea VPN-bedrijfsapplicatie. En ik ben de constante flow aan updates en fouten meer dan beu...

bloated valt wel mee toch? probleem lijkt me vooral te zijn dat er geen echt alternatief voor java is (wat ook op dezelfde systemen als java draait)

Tijd voor een reactie van de consumentenbond.
Ik denk dat er wordt aangeraden om helemaal geen gebruik meer te maken van internet totdat de patch is uitgebracht, aangezien dit keer alle browsers hiervoor gevoelig zijn

[Reactie gewijzigd door Mikemkm op 26 september 2012 11:09]

Gewoon Java uitschakelen als je je zorgen maakt. Toch wel jammer dat mijn favoriete programmeertaal zo slecht in het licht staat de laatste tijd..

Ik installeer dat al jaren niet meer. Kan best zijn dat het nog veelvuldig gebruikt wordt bij bedrijven, of op jsp websites, maar voor de gemiddelde gebruiker heeft het nog weinig zin om lokaal de runtime te hebben ... Java applets behoren tot het verleden, en ik heb zelf nog nooit applicaties gehad die in Java zijn geschreven.

Vroeger had ik inderdaad ook altijd Java (JRE) geïnstalleerd staan, maar de laatste paar jaar niet meer en ook nooit gemist (ook geen sites die er om vroegen). Wordt JRE eigenlijk nog wel zoveel gebruikt?

Volgens mij nauwelijks. De enige Java-based deskop-apps die ik gebruik zijn ontwikkeltools voor, je raad het al: Java-based software Een normale consument gebruikt dat uiteraard niet en heeft in een normale situtatie dus ook geen JRE nodig.

Ik weet dat veel studenten JAVA nodig hebben omdat het bij veel universiteiten gebruikte Blackboard (online studieomgeving) dat blijkbaar nodig heeft voor bepaalde tools.

Minecraft gebruikt Java. Met 7,535,045 spelers een aardig target. Minecraft is de enige reden dat ik Java op mijn computer heb.

Ik ben benieuwd hoe lang het duurt voordat Oracle met een patch komt, dit is een gevaarlijke exploit.

Runescape en Minecraft zijn 2 populaire voorbeelden van pure Java applicaties. Voor desktop apps zie ik het inderdaad verder niet veel, maar op internet zie ik nog relatief veel applicaties die Java gebruiken.

Toch blijf ik erbij dat Java een geweldige programmeertaal is. Het is krachtig, multiplatform en vrij eenvoudig in gebruik met een enorme standaard library aan ingebouwde functionaliteit.

Ik heb meerdere java appalicaties. Ook de meeste apps op een android telefoon zijn java, in die zin heeft java de afgelopen jaren een enorme opmars gemaakt.

Java applicaties worden meestal gecompileerd naar een native taal

Ik dacht het dus niet...

Maar gaat dit dan om gewoon de JVM op je machine hebben en je bent vulnerable?
of gaat het alleen om de browser plugin, en moet je met java-browser-plugin naar een website toe gaan die deze hack toepast?

Ik vind het altijd jammer dat in beveiligings lekken nieuwsgeving hier nooit onderscheid in gemaakt wordt, terwijl een linux server die via java een een webservice aanbied iets heel anders is dan een website die een java-applet gebruikt. (iets wat zo veroudered is en wat bijna niks meer te maken heeft met hedendaags java-programmeren: vooral serverside)

dit lijkt voor mij heel sterk op negatieve propaganda, vooral zo vlak voor de conferenties (die toch echt niet over applets gaan)
het geeft een vertekend beeld, iets wat ik beneden peil vind voor tweakers om zo over te nemen van andere nieuws sites, en of de onpartijdigheid of de vakkundigheid van Joost Schellevis ter discussie stelt.

P.S. hierbij moet ik aangeven dat ik zelf niet onpartijdig ben, ik ben dan ook geen verslaggever.

[Reactie gewijzigd door Artimunor op 26 september 2012 12:28]

Niet de taal Java is kwestbaar maar de runtime environment (JRE) van Oracle bevat de fout. Ongeacht of jij nou een service via de JRE of dat een applet de JRE gebruikt de fout maakt het mogelijk dat code buiten de sandbox kan worden uitgevoerd.

Maar op een webserver plaatst iemand niet zomaar even een java applicatie. Maar je kunt niets uitsluiten, want als een hacker via een andere exploit java byte code op jouw server weet te krijgen en het daarna draaiend krijg ben je nog steeds vatbaar.

Maar applets zijn wel de gemakkelijkste manier om deze bug te exploiten. Ik ben al zeer lang niets meer gedaan met java applets. In MSIE kon ik destijds niet de applet verbergen (CSS visibility) net zoals dat langere tijd niet kon met de standaard dropdown in IE. En anders kun je de applets nog wel verbergen op een positie buiten beeld en daar de code draaien.

Ik zou dan ook graag zien dat browsers in de toekomst voortaan plugin content (java, flash, silverlight, etc) standaard een prompt geven of deze geblokkeerd moet worden, uitgevoerd mag worden en of 'content' van deze bron in de toekomst op dezelfde manier moet worden verwerkt (prompt antwoord wordt onthouden voor FDQN).

Dat maakt het een stuk lastiger om exploits in plugins bij het grote publiek te krijgen.

Meestal kun je het risico al flink verkleinen/praktisch weghalen door geen java plugin te gebruiken in je browser.

Bij het IE lek sprong iedereen er bovenop. De ernstige Java lekken (dit is de zoveelste in zeer korte tijd) krijgen gek genoeg niet die aandacht. De Consumentenbond en anderen waren er als de kippen bij om te zeggen dat mensen IE moesten laten staan. Maar als een plugin lek is hoor je ze niet. Imho is dit nog veel erger.

Oracle doet ook weinig om de boel op te lossen. Patches kan je lang op wachten en vaak bevat die nieuwe interessante bugs.

De CB gaf dit aan omdat de duitse overheid het adviseerde en men wilde deze informatie het Nederlandse publiek niet onthouden.
Of denk je dat er in Duitsland alleen amateurtjes zitten zonder enige kennis van zaken die lukraak een advies uitbrengen?

Het feit dat men geen advies voor dit onderwerp heeft uitgebracht, betekent blijkbaar dat het minder ernstig is dan het lek in IE (ik zeg dus niet dat dit lek niet ernstig is, alleen niet ernstig genoeg).

wat verwacht je anders van zulke organisaties? Feit is wat Jive al aangeeft de aanvallen verplaatsen zich.
Uiteindelijk kun je beter de pc uit hebben staan of geen enkele verbinding hebben met een netwerk dat is het meest veilig.

Zolang we internet hebben zullen er aanvallen blijven bestaan. Zaak is je iets beter voor te bereiden als een ander de makkelijkste prooien worden het eerst gepakt.

Ik heb mijn aandeel in postduiven weer ingekocht!

eet smakelijk alvast

ik dacht precies het zelfde

Ik draai al een paar weken geen Java meer op mijn computer :-). Heb dat maar uitgeschakeld met al die lekken

Haha, aub niet, ik werd al dood gebeld door bezorgde burgers die IE gebruikten.

Heb nooit echt gehouden van java, maar dat is vooral vanwege de erg slechte integratie en de performance van de meeste ( hoogstwaarschijnlijk niet fatsoenlijk geschreven ) java applicaties. Tevens vind ik het ontwikkelen in de taal een vervelend proces aangezien het je echt loopt te moederen en je niet dingen laat doen die bepaalde development processon zou kunnen versnellen.

Zo heb ik het toetsenbord-layout Dvorak-qwerty, wat er voor zorgt dat ik CMD+A etc. nog gewoon kan gebruiken op de gebruikelijke qwerty locatie terwijl ik wel snel kan tikken in dvorak. 3x raden: yup, java snapt dit niet en werken in eclipse is dus minder dan prettig.

Dus eigenlijk is het geen probleem van Java mar van je Eclipse IDE?

Ik dacht eerst dat het probleem bij eclipse lag ( en werd dus behoorlijk pissig op het programma als gevolg ) maar het is telkens bij elke java applicatie dus ik denk dat er iets in de event stack of hoe keystrokes ook worden gehandled in java applicaties over het algemeen niet fatsoenlijk is geimplementeerd, ik weet niet precies hoe high level de code die er voor zorgt dat dvorak-qwerty goed werkt precies is maar ik denk dat het een stuk hoger ligt dan de normale mapping van je toetsen.

Het werkt fantastisch in apps die geschreven zijn met de normale systeem libraries.

[Reactie gewijzigd door jabwd op 26 september 2012 11:55]

Ik denk dat je probleem bij Java's implementatie voor OSX ligt. Misschien dat met Java7 dit gefixed is gezien Oracle nu releases doet voor OSX (maar Oracle kennede, waarschijlijk niet).

Ik heb tijdje in Java met Android gekeken en ik werdt gek van.De.Vele.Methodes.Met.HoofdLetters.ElkeKeer.Weer.Met.HoofdLetters()

echt bizar.

C# gebruikt die notatie, java's methodes starten met kleine letter, en dan pas hoofdletters:
getThis(), doSomethingCool().

De conventie is methodes zonder hoofdletters te beginnen en daarna camelCase te gebruiken.

Tja, dat is gewoon afhankelijk van welke conventie je gebruikt, ze liggen namelijk helemaal niet vast...

Mooi, eindelijk iemand die het lek niet openbaar maakt en op pastebin oid gooit...

Dat zij niet zeggen dat het lek al bekend was bij een select groepje mensen en dat daar actief misbruik van wordt gemaakt.

Recent voorbeeld zijn de auto's die gekraakt worden. Er waren geruchten zat dat er een methodes moesten zijn dat auto's zonder schade werden meegenomen. Totdat een universiteit er mee aan de slag ging en het daadwerkelijk reproduceerde.

Nee hoor; zijn al sinds 2007 bekend van o.a. BMW

Jammer, had toch liever deze code in het wild gezien en wereldwijde paniek.

Jij was ook op een recent facebook feestje? Welk doel dient wereldwijde paniek? Worden daar de problemen sneller door opgelost of juist langzamer? Ik vermoed het laatste.

Ik vind het al heel wat dat 'ie hem niet via thegrugq op de zwarte markt verkoopt voor €500.000+

Een java 0-day van dit niveau, als het robust gemaakt is om op meerdere platforms en versies code execution te krijgen, dan is dat echt makkelijk een half miljoen waard...

Java staat bij mij allang niet meer geïnstalleerd, geen idee waarvoor ik het nog moet gebruiken. Spelletjes websites? Kom ik niet op, mijn standaard browse sites gebruiken het ook niet.

Volgens mij is er inderdaad geen enkele reden om anno 2012 nog Java op een desktop-PC geinstalleerd te hebben, behalve natuurlijk als je dingen doet met Java-development (zols ik), maar dan weet je er waarschijnlijk genoeg van om de browser-plugins niet te installeren, wat het risico behoorlijk beperkt.

Java staat al jaren in mijn Browser uit. Er zijn zelden websites die ik tegenkom waar je Java bij nodig hebt terwijl er redelijk vaak exploits verschijnen voor Java. Tip dus ook voor anderen: Gewoon Java uitschakelen in je browser, want je mist hem waarschijnlijk toch niet (Anders kan je hem ook weer aan zetten).

Hey, hoe schakel je Java uit in Firefox? Ik kan Javascript uitschakelen, maar dat is niet hetzelfde...

Java gewoon niet installeren?

Als je het genstalleerd hebt, staat Java bij je plug-ins (Java Applet Plug-in o.i.d.). Gewoon op knopje disable drukken.

Keypunchie, bedankt. Dat is inderdaad het eenvoudigste.

Dit begint langzaam een vervelende geschiedenis te worden. Vaak blijkt Oracle van serieuze problemen te weten en er niets mee te doen. Ik weet of of deze praktijk pas begonnen is met de overname van Sun, maar het voorspelt niet veel goeds voor andere producten.

De gebruikers die MySQL nog niet voor Postgres hebben ingewisseld zouden zich zorgen moeten maken.

edit: dit soort voorbeelden.

[Reactie gewijzigd door snirpsnirp op 26 september 2012 11:13]

Tja, of het zijn problemen die gewoonweg niet simpel zijn op te lossen..

Het is natuurlijk utopie te denken dat iets 100% veilig kan. Java is natuurlijk een mooi target omdat het zo veel gebruikt wordt.

[Reactie gewijzigd door matty___ op 26 september 2012 12:48]