Apple blokkeert Java op Mac OS X

Apple heeft de Java-plug-in op OS X geblokkeerd nadat er een beveiligingslek is ontdekt. De software van Oracle staat op een blacklist en wordt waarschijnlijk pas gedeblokkeerd als het beveiligingslek door Oracle is verholpen.

Dat ontdekte Macrumors, die een verwijzing naar de blokkade van de Java-plug-in vond in het Xprotect.plist-bestand. Daarin wordt een Java-versie vereist die nog niet bestaat, waardoor effectief bestaande Java-plug-ins worden geblokkeerd. Apple voerde de blokkade door via een update van het Xprotect.plist-bestand, iets dat werkt voor gebruikers van Mac OS X versie 10.6 en hoger. Bij oudere versies kan Java alleen handmatig worden gedeïnstalleerd.

Hoewel er geen officiële verklaring is uitgegeven, is het aannemelijk dat de blokkade is doorgevoerd nadat er een beveiligingslek is ontdekt in Java. Die stelt kwaadwillenden in staat om via een exploit ongemerkt software te installeren op de computer van de gebruiker. Eerder kwam al naar buiten dat het lek misschien al wordt misbruikt. Eerder verwijderde Apple al de plug-ins voor Java uit zijn browser, waardoor deze niet meer standaard staat geïnstalleerd. Ook maakt Java sinds versie 10.7 geen deel meer uit van OS X.

Naar aanleiding van de ontdekking van het beveiligingslek in Java heeft de Amerikaanse overheid geadviseerd om geen Java meer te gebruiken. De overheidsinstantie US-CERT raadt, evenals onder andere de Nederlandse overheid, gebruikers aan om de bewuste plug-ins in hun browsers uit te schakelen.

Reacties (164)

Beetje misleidende titel. Apple blokkeert Java browser plugin, niet Java.
Ze waren er dit keer erg snel bij. De blokkade was snel na het bekendkomen van de lek actief.
Echt lijkt het wel een beetje rigoureus. Ik weet nietof Apple ook ergens een security bulletin heeft, maar het informeren over dit soort acties is toch wel een must. Men wil toch wel weten dat als men iets blokkeert wat dit van effecten heeft.

Misleidende titel is het wel, maar volgens mij geld het lek voor de plug-in en Java zelf ook. Maar voor er onveilige code in de niet-plug-in uitgevoerd kan worden moet het geïnstalleerd worden door jou zelf, of komt het via de plug-in binnen. Door de plug-in te blokkeren ben je eigenlijk al helemaal binnen: het blokkeert alle eventueel gevaarlijke online Java applets.

De enige gevaarlijke manier van aanvallen is via de plug-in. De aanval maakt weliswaar gebruik van een bug in de Java VM permissies (waardoor de "sandbox" permissies van de plug-in worden omzeild), maar dat betekent verder niet zoveel Java desktop-applicaties. Die hadden namelijk al geen restricties (net als "gewone" desktop-applicaties).

Wie zich nog wel zorgen zouden moeten maken, zijn aanbieders van shared Java webapp hosting. Servlet-containers maken ook gebruik van het Java permissies-systeem om te voorkomen dat een webapp bijv. de hele servlet container down brengt met een "System.exit()" call. Ik kan me voorstellen dat dat nu ook kwetsbaar is.

Leuk en aardig maar ik zie alleen maar stukje xml tags met wat waarden.
Zie nergens een bewijs van blokkade ...

Wat je ziet is de definitie file van xprotect, wat een vrij nieuwe OSX security tool is waarmee men malware en andere kwaad aardige code kan blokkeren.
Die .plist kan je gewoon met een editor bekijken.
Xprotect download zelf automatisch definities van de Apple servers.
Blokkade is er wel degelijk, ik heb ook al vragen hierover in het forum gezien.

Het systeem zoals het nu is stamt uit Snow Leopard. In Leopard zaten al stukken van dit systeem en werd het al gebruikt om bijv. internet downloads te blokkeren. Van "vrij nieuw" is dus geen sprake. Het systeem groeit wel en wordt steeds volwassener. Zo is het sinds Mountain Lion mogelijk om dagelijks op updates te controlleren wat in voorgaande OS X versies niet gebeurde. Het systeem zelf is ontzettend eenvoudig. Al z'n definities staan in 2 .plist bestanden (dit zijn xml files vandaar ook de xml syntax):

• /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
• /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

De eerste genoemde bevat de definities van malware zoals de bekende Flashback en de tweede bevat de te blokkeren plugins. Hierbij gaat het echter om specifieke versies van de plugins. Op dit moment staan er 2 in: Flash 11.3.300.271 en Java 1.7.0.10.19. Alles lager dan dat qua versienummer wordt geblokkeerd. De huidige Java versie is overigens 1.7.0.10.18 en wordt dus geblokkeerd. Heel simpel systeem maar wel effectief. Het herkennen van de malware zoals Flashback is wat minder simpel, dat zit meer in lijn met wat de rest van de virusscanners/malwarescanners doen.

Mocht je nou erg graag zelf in Mountain Lion deze files willen updaten dan kun je op de commandline middels Terminal het volgende commando uitvoeren: sudo /usr/libexec/XProtectUpdater
Wel even je wachtwoord invullen en op enter drukken. Vergeet ook niet de hoofdletters in het commando want het is hoofdlettergevoelig.

Testen of de blokkade werkt is eenvoudig: open Safari, surf naar java.com en klik op de optie "heb ik al Java?". Hij zal daarna een Java check uitvoeren waarbij hij de plugin nodig heeft. Als de plugin geblokkeerd wordt krijg je daar een melding van met de optie om de nieuwste versie te downloaden (wat nu niet werkt omdat die er nog niet is).

[Reactie gewijzigd door ppl op 12 januari 2013 17:13]

Aan de overweldigend negatieve reacties hier is het nogmaals duidelijk dat een hoop "tweakers" ofwel Apple haters zijn, danwel buiten de realiteit leven.

Java is uitgeroepen tot meest onveilige software ter wereld in 2012 door Kapersky. Het Amerikaanse ministerie van BiZa adviseert om Java plugins vanwege dit nieuwe lek meteen te disablen. Apple doet dat en handelt daarmee op de juiste manier.

Maar goed, een hoop alu-hoedjes hier verkiezen de "vrijheid" om gevaarlijke software te draaien boven de veiligheid van de 99.9999% van de mensheid die de plugin nooit gebruikt maar er wel een reëel risico mee loopt zolang het niet uitgeschakeld is.

Het is een simpele afweging waarbij de veiligheid van de overweldigende meerderheid van de gebruikers het zwaarst weegt. Zeker gezien het feit dat de plugin amper gebruikt wordt en zo een ernstig lek bevat is het een no brainer dat uitschakeling de beste weg is.

Iedereen die werkelijk vindt dat het uitschakelen van zo een plugin onder deze omstandigheden een slechter alternatief is dan het risico voort te laten bestaan leeft niet op deze planeet, maar in een techno bubbel.

In deze draad staat volgens mij de veiligheid of onveiligheid van het Apple OS, of de onverstandigheid van Apple's actie helemaal niet ter discussie. Waar haal je dat vandaan?

De discussie is een andere. Ik zie hierin twee lijnen:

(1) Het uitzetten van de Java functionaliteit binnen de browser mag op zich verdedigbaar zijn, de wijze waarop Apple dit heeft gedaan, is onhandig te noemen. Door op een transparante manier de Java plugin uit te schakelen had Apple de discussie bij zichzelf weg kunnen houden. De techniek die is gebruikt had hetzelfde kunnen zijn, maar een update melding in de browser, zoals Firefox ook wel hanteert, had gebruikers kunnen informeren over de genomen actie en het waarom. Ik weet zeker dat een ieder dan de vlag en wimpel voor Apple had uitgestoken. Van een bedrijf dat veel investeert en ervaring heeft in corporate communicatie had ik een meer gestroomlijnde actie verwacht.

(2) Een tweede lijn is een discussie over de wijze waarop frameworks als Java, maar ook bijvoorbeeld .NET in de OS'sen geintegreerd zijn, en wat dit voor consequenties heeft. Deze discussie is een algemene die niet per se met het Apple OS te maken heeft.

Dat Kapersky en het Amerikaanse ministerie van BiZa iets roepen zegt wel iets, maar ik vind het steeds moeilijker te duiden wat precies. Makers van virusscanners kunnen zo hun eigen redenen hebben om dit te communiceren. Zonder hiermee iets te insinueren, het kunnen hele eerbare redenen zijn. Het Amerikaanse ministerie van BiZa zou ik niet als deskundig willen omschrijven, die roeptoetert maar na. Zegt denk ik niet meer dan "paniek reactie van een samenleving met blinde angst".

edit: typo's

[Reactie gewijzigd door teacup op 13 januari 2013 22:16]

defineer gevaarlijk.... voor mijn imac altijd met windows gewerkt, vroeger toen ik jong was zat virussen gehad. maar wat is het ergste dat er gebeurd is? weer een clean install, wat jekker is on al je documenten weer eens uit te zoeken. schoon begin was zo gek nog niet.
ik bepaal zelf wel of ik het gevaarlijk genoeg vind. geef een waarschuwing af en laat de consument bepalen. ik heb het product toch gekocht ik leen het niet!
mijn laatste imac dit. ..

Wat een onzin. Als Microsoft dit deed had ik ook niet positief gereageerd. Er zijn genoeg onveilige systemen op deze aardkloot. Maar blokkeren is echt kansloos. Je moet zelf kunnen bepalen om iets te blokkeren/beveiligen. Ik ga jou toch ook niet verplichten je deur op slot te doen.

Ik ga jou toch ook niet verplichten je deur op slot te doen. (over onzin gesproken)

Nee dat hoef jij ook niet want dat doen de verzekeringmaatschappijen al; die keren niet uit als er geen braaksporen zijn.
Dus tenzij jij je mooie spulletjes niets waard vindt zet je heel snel een slot overal op.

Laat ik zeggen dat, zelfs al is er niets weg, je je heel ongemakkelijk voelt als iemand je huis, daar waar jij je veilig hoort te voelen, overhoop heeft gehaald.
Dan is jouw volgende stap sloten plaatsen of verhuizen.

Maar vertel vertel vertel....waar staat jouw huis zonder sloten?
Vertel ook meteen even al je persoonlijke gegevens (pasnr, sofi etc), je bankgegevens en je pincodes...
Hoeft niet per mail of private message, zet het maar gewoon hier neer, zodat iedereen het kan lezen....wel zo makkelijk voor ons.
En als ik of een ander toch langskom leg dan meteen even de autopapieren met sleutels klaar.....
We nemen alles mee, hebben we er zelf niets aan dan verpatsen we het wel voor 1/1000 van de aanschafwaarde.
Jij hecht er blijkbaar toch geen waarde aan.
Of heb je liever privacy en bescherm je jouw bezit zo goed als mogelijk?

Zoiets is deze exploit ook namelijk......

[Reactie gewijzigd door Teijgetje op 14 januari 2013 04:26]

Wederom een zwaar overtrokken reactie.

Zoals ik al eerder zei ligt de prioriteit van een bedrijf niet bij dit soort bangmakerij maar bij het uitvoeren van het werk.

Apple neemt in ieder geval maatregelen tegen het java lek.

Ik zou er helemaal niet blij mee zijn als Microsoft zoiets zou doen van huis uit, want ik gebruik 4 echte pure Java programma's met bepaalt Grafisch werk, dan zou in principe Microsoft mijn werk gaan belemmeren en daar zou ik niet blij mee zijn, net zoals mijn klanten. Beter een onveilige Java op het programma Timefreeze draaien (virtueel) dan helemaal niet draaien op standaard Windows zonder Virtueel programma.

Apple heeft alleen de browser plug-in uitgeschakeld, niet heel Java. Dat is ook nergens voor nodig, aangezien de aanval via de plug-in loopt.

[Reactie gewijzigd door Herko_ter_Horst op 12 januari 2013 12:43]

Voor Microsoft is het lastiger, aangezien die helemaal niks meer met Java te maken hebben, Dan is blokkeren een lastig verhaal. Apple ontwikkelt nu samen met Oracle de oS X versie van Java dus dan zijn exploits ook hun verantwoordelijkheid.

Apple ontwikkeld helemaal niets samen met oracle, dat deden ze vroeger maar nu niet meer. Ze hebben alles overgedragen.

Tot aan Java 6 deed Apple zelf de JRE distributies, tegenwoordig is Oracle verantwoordelijk voor de release cycle, maar Apple is nog steeds mede-ontwikkelaar in het OpenJDK project voor de OS X client.

Persbericht van Apple zelf:
http://www.apple.com/pr/l...Project-for-Mac-OS-X.html

De code is allemaal open source, Apple had zelf het lek kunnen vinden, fixen en Oracle vragen om een update te pushen. Daar zijn ze nu ongetwijfeld mee bezig, en in de tussentijd wordt de plugin in OS X uitgezet. Da's IMO helemaal zoals het hoort, al hadden ze het misschien iets duidelijker mogen communiceren.

Op Windows is het een ander verhaal, Microsoft heeft na de rechtszaken in de jaren 90 zijn handen helemaal van Java afgetrokken. Als er een exploit in zit - Oracle's probleem. Bij Apple ligt dat, als mede-ontwikkelaar, wat anders.

[Reactie gewijzigd door Dreamvoid op 12 januari 2013 16:23]

dat doe ik liever zelf

Second that. Na het lezen v/h lek gisteren heb ik gewoon zelf Java disabled (ben een Win 7 gebruiker).

Maar dat neemt niet weg, dat voor de meeste mensen die computers gebruiken het beter automatische kan gebeuren. Zij lezen geen techsites of kunnen het zelfs niet uitschakelen als ze zouden willen.

Ik ben in ieder geval blij dat dit niet automatische bij mij gebeurt, want ik persoonlijk zit er niet op te wachten.

Ik ben het deels wel met je eens, automatisch zou voor sommige mensen beter zijn. Maarrrr wat ze naar mijn idee beter hadden kunnen doen is een venster voorschotelen (zoals Chrome dat doet voor gevaarlijke websites) waarbij er toch een optie zit om door te gaan. Want nu gaan mensen klagen omdat ze bepaalde dingen in 1x niet meer kunnen gebruiken, met sommige gevolgen van dien.

Een waarschuwing zou wel op z'n plaats zijn vind ik.

Firefox doet dit vanaf versie 17. De plugin wordt uitgeschakeld middels de click to play functionaliteit. Als je een site met Java elementen bezoekt zul je een waarschuwingsschermpje krijgen met de melding dat Java is uitgeschakeld en de optie om 'm voor die site toch weer aan te zetten. Daardoor ben je wel beschermd zonder dat bepaalde zaken zoals bedrijfsapplicaties niet meer toegankelijk zijn. Scheelt ook in beheer omdat je alleen gebruikers hoeft te instrueren en niet allerlei hackwerk uit moet voeren om het weer werkend te krijgen (zoals met OS X wel het geval is).

Safari geeft je trouwens ook een melding dat Java niet werkt met de optie om de nieuwste versie te downloaden. Dat heeft dus nu nog geen zin omdat er geen nieuwe versie is. Levert weer wat onduidelijkheid bij een gebruiker op en dat is jammer.

Het is alleen jammer dat je in Firefox niet eenvoudig met een group policy hier een exclusion list van kunt aanleggen (dus bedrijfsapps excluden zodat Java voor die sites wel weer aan staat). Bij OS X zul je de Xprotect settings moeten gaan aanpassen en het updaten hiervan uitschakelen. Dat is nog wel te scripten maar hier zijn het weer de thuisgebruikers waar het op mis zal gaan.

Bij OS X kan je Xprotect via MCX beheren, zoals dat hoort bij enterprise clients.

Maar het gros van de PC en Mac gebruikers zegt zo'n waarschuwing helemaal niks. Dus je creeert alleen maar verwarring.

Als je dat voor alle potentieel gevaarlijke code doet (dus ook Javascript) dan blijf je klikken.

wellicht maar het is nog altijd beter dan ineens die bedrijfcritisch app niet meer kunnen starten...

Als je zo'n idioot bedrijf hebt dat de enterprise tools van de leverancier van de hard- en software niet aanpakt, dan ben je sowieso al verkeerd bezig. Raar opkijken om dat je bedrijf gevild wordt door consumenten-issues is dan ook gewoon je eigen schuld.

Persoonlijk zou ik er niets op tegen hebben als welke software dan ook zichzelf zou uitschakelen als er een ernstig genoeg lek word gevonden. Natuurlijk, in 'nood' situaties kan dat niet leuk zijn, maar als dat je computer serieus veiliger houd vind ik dat toch wel een kleine prijs om te betalen.

Hoe dan ook, ik klaag bij Apple over van alles en nog wat, maar voor dit alleen hulde.

En trouwens@nexhill, java is alles behalve de onveiligste software ooit... ik bedoel, genoeg andere software heeft een stuk meer kritische bugs gehad. (Inclusief software zoals browsers die op een nog kritischere plaats draaien)

Ben toch benieuwd hoe ze dat op kantoor zien als er een lek in bijv. windows server gevonden wordt en alle servers zichzelf dus maar uitschakelen omdat het in een essentieel deel zit .

In bepaalde contexten zal het best prettig zijn, in anderen absoluut niet. Het is voor software/fabrikant echter bijzonder lastig te bepalen in welke context dat het draait, wat de gebruiker daar van vind, etc.

Kan ik ook wel inkomen.

Stel je werkt in je onderneming met iMacs of iets anders, en op je intranet website host je een eigen java applicatie of iets gelijkaardig.

Plotseling kan je er niet meer op, omdat Apple het nodig vind om de software gewoon eventjes uit te schakelen.

Je kunt in een server-client omgeving op de Mac instellen dat updates alleen van jou server komen. Zo kun je updates die specifieke toepassingen onbruikbaar maken achterwege laten. Hetzelfde kan je instellen in een Microsoft netwerk overigens. Heel veel bedrijven maken hier gebruik van.

Dat gebeurt dan ook, als er een bepaald ActiveX lek gevonden wordt door Microsoft dan kunnen ze dat met een patch uitzetten totdat er een definitieve fix is.

Jij bent niet de enige op deze wereld.

Genoeg mensen die niet weten wat Java doet/is.
Er zal vast wel een workaround voor je te vinden zijn, kun je lekker zelf bepalen of je java weer aan zet en met de onveiligste software ooit verder browst

[Reactie gewijzigd door nexhil op 12 januari 2013 12:25]

wat een troll ben je toch net of er geen andere manieren zijn om een systeem te beveiligen, er zijn genoeg bedrijven die nog met windows nt werken omdat er geen mogelijkheid is om bepaalde systemen fatsoenlijk te updaten of zo duur is dat het compleet onrendabel is (en wellicht miljoenen of zelfs miljarden, zou kunnen kosten)... wat je dan doet is simpel. zorgen dat een shitload aan beveiliging omheen zit waar zelfs de de geheime dienst bang van wordt...

het is gewoon niet aan apple om simpelweg wel even te bepalen wat je wel en niet mag draaien op je mac.... het lijkt verdorie steeds vaker voor te komen dat je een mac niet koopt maar huurt... DAT is pas een security-issue. straks komen ze nog met maatregelen om te bepalen of je je mac niet gebruikt voor dingen waar apple tegen is (bijv het ontwerpen van een nieuwe iphone-concurent), of een manier om een jailbrake te bouwen... en worden je productie-machines zo naar /dev/null gestuurd...

het is maar waar je blij van word.... maar als ik in een dictaat wil leven ga ik wel naar korea...

99% van de gebruikers zal Java niet zelf uitschakelen. Daarom is het goed dat Apple ze er eventjes bij helpt.

Tje das waar. Maar kijk we kunnen allemaal maar zeggen ''zert java uit, zet java uit''. Maar de meeste mensen weten amper hoe. Die denken '' oo als ik da gele programmatie uitzet (java dus) gaat mijn computer crashen''. Dus ja logisch. Maar dit is niet alleen maar voor apple en haar cosumenten zelf. Maar Apple wil ook een signaaltje naar Apple sturen van. '' hee Oracle DICHT DAT BEVEILIGINGSLEK TOCH'' . Ik hoop dat deze actie van Apple Oracle bewust maakt dat ze minder lui moeten zijn.

Het is een zero-day exploit dat gevonden is en in alle versies zit.
En waarvan de exploit al via internet circuleert.
Dat dicht je niet een, twee drie, Oracle is dan ook niet van luiheid te betichten in deze.
Het laatste zero-day exploit, in augustus was snel gepatched door Oracle die daarna later met een update kwam.
Zoals je kunt lezen is dit een gevaarlijk lek en is het dus zaak dit aan gebruikers duidelijk te maken.
Aan Applegebruikers is dit niet echt duidelijk te maken omdat ze vaak geen idee hebben wat software inhoudt, ze gebruiken het en het werkt voor hen.
Vandaar dat Apple ingrijpt.

Zie het als dat Apple een beetje de kerk is die je vertelt wat goed en slecht is en de lat wat strenger legt dan je misschien zou willen, de atheïsten (windows) denken zelf en willen dat alles mogelijk is, maar eigenlijk komt iedereen uiteindelijk tot vrijwel dezelfde richtlijnen/geboden.
Apple doet dus niets fout maar probeert zijn volgelingen te behoeden voor "zonden".
En de atheïsten die geen notie hebben van dit dreigende gevaar zijn dus extra kwetsbaar omdat ze geacht worden zelf te denken.......Microsoft grijpt vaak pas in bij derdensoftware als het echt niet anders kan.

[Reactie gewijzigd door Teijgetje op 13 januari 2013 22:35]

Neen, de eindverantwoordelijkheid hoort bij de gebruiker te liggen. Stel ik heb java toch nodig, dan ben ik vandaag niets meer met mijn mac, moet ik naar een ander OS omschakelen. Apple kan beter een waarschuwing tonen wanneer java gestart worden en vragen aan de gebruiker of hij zeker is dat hij verder wenst te gaan.

Java word dan ook niet uitgeschakeld, er word een hogere minimum versie ingesteld die voorkomt dat gebuikers niet meer kwetsbaar zijn voor de betreffende lek. Het lijkt er overigens op dat Mozilla hetzelfde heeft gedaan.

[Reactie gewijzigd door PrisonerOfPain op 12 januari 2013 19:40]

Die versie bestaat nog niet.

Daarin wordt een Java-versie vereist die nog niet bestaat, waardoor effectief bestaande Java-plugins worden geblokkeerd.

Dus ze zijn inderdaad niet meer kwetsbaar, maar je kan ook niets!

De exploit is inmiddels een paar dagen oud, waarschijnlijk komt Oracle na het weekend gewoon met een update. Tot die tijd moet je gewoon geen Java draaien, de 0-day exploit is al redelijk vaak in het wild tegen gekomen en iedereen die het doet is kwetsbaar. Aangeraden word om naar Java 6 te downgraden, maar of je dat nu voor die paar dagen wilt doen is natuurlijk ook nog maar de vraag.

Vooralsnog hebben Apple en Mozilla de bal nu in Java park gelegd, het is niet hun verantwoordelijkheid om met een daadwerkelijke fix te komen; het is wel hun verantwoordelijkheid om hun gebruikers veilig te stellen. Dan maar even een Java, dit is alleszins de schuld van Oracle en niet die van iemand anders.

Nee, Apple moet die gebruikers waarschuwen dat er een lek zit in Java en dat je verder kunt op eigen risico. Zo geef je ook de onwetende gebruiker een keuze: het risico lopen (als je dat niet kunt inschatten, moet je dat niet doen) of veilig het advies van Apple volgen: Java niet gebruiken.

Het verleden heeft aangetoond dat dat absoluut niet werkt. Mensen klikken domweg op ja. Er zijn zeer veel verhalen bekend van malware die geïnstalleerd wordt doordat de gebruiker gewoon op ja klikt.

Zeker bij OSX, wat juist mensen aan spreekt die verre van Tweakers zijn heeft Apple een zorgplicht. Die voeren ze hier uit.

punt is wel dat sommige sites java nodig hebben, dus of dit nou de beste oplossing is weet ik niet, ook veel bank websites gebruiken namelijk Java. (of dit verstandig is doet er even niet toe maargoed) en mensen die werken op een mac kunnen dus niet naar die sites om hun zaken te regelen.

dus goed en fout is relatief.

als apple wil helpen kan apple toch gewoon een popup scherm bij gebruikers neer zetten met de mededeling dat er een ernstig lek in java zit en dat apple adviseert om het uit te schakelen? en dat ze dan de optie geven om het via apple uit te schakelen of dat ze het zelf uitschakelen of dat ze er niets mee doen? apple is toch niet degene die voor mij kan bepalen of ik iets uitgeschakeld wil hebben ja of nee? dat is mijn keuze.

als MS met windows 8 komt en de metro interface zonder start knop is heel tweakend NL van de leg omdat MS voor hun bepaald dat ze de metro interface moeten gebruiken maar apple mag wel zonder aankondiging software op jou apple pc blokkeren.

het is gewoon niet aan apple om simpelweg wel even te bepalen wat je wel en niet mag draaien op je mac

Je hebt een punt, al is het wel zo dat Apple in dit geval software uitschakelt die ze zelf met het besturingssysteem meegeleverd hebben, en niet zomaar een programma als bijvoorbeeld firefox uitschakelt, dat door gebruikers zelf geinstalleerd is.
Het is te vergelijken met Microsoft die in een update de messenger service uitschakelt omdat deze te onveilig blijkt te zijn.

Nee, want de Messenger Service is van Microsoft. Daarnaast is dat ook een wenselijk geval, want de 99.999% van de normale gebruikers zullen het zelf niet doen.

ja dat klopt, maar als Apple STANDAARD Java meeleverd dan zullen de meeste mensen hen ook verantwoordelijk houden. Apple doet er dus beter aan dat dus in 100% van de gevallen tegen te gaan dan dat ze in 1% van de gevallen een probleem krijgen want 1% is al veel te veel. Apple werkt nog steeds met de filosofie dat als iets niet volledig werkt zoals het moet, dat het dan beter is dat je er niet eens mee begint. Daarin geef IK ze groot gelijk. Als jij vind van niet.... tsja... jouw mening

het is gewoon niet aan apple om simpelweg wel even te bepalen wat je wel en niet mag draaien op je mac.... het lijkt verdorie steeds vaker voor te komen dat je een mac niet koopt maar huurt...

Microsoft is er anders ook niet vies van om active X componenten in hun updates te blacklisten waardoor ze plotseling niet meer werken in je Internet explorer.

Je zet twee totaal nutteloze dingen tegenover elkaar, en daarna pak je ook nog wat fantasie en een gefaalde flame, om aan te duiden dat er misschien wel een situatie is, waarbij Xprotect niet gewenst is.

In plaats van te mekkeren kan je ook gewoon bedenken dat mensen die geen invloed van buiten af willen toch al niet op internet zitten. Daarnaast zullen mensen die wel op internet willen, maar een Mac, met Mac OS X 10.6 of nieuwer hebben, zelf Xprotect blokkeren.

Xprotect is goed, het is goed in wat het doet, en het moet het precies zo blijven doen. Dat jij nou die 1% bent die het niet leuk vind zegt alleen wat over jou. De 99% van de gebruikers die niet eens weten wat Java is, worden hier ook alleen maar mee geholpen.

Ga jij maar lekker Windows NT draaien.

Ons bedrijf heeft ook enkele essentiele programma's lopen die java nodig hebben. Zomaar afsluiten zou voor ons veel shade betekenen. Ik ben van mening dat onze administators zelf moeten kunnen beslissen wat geblokkeerd wordt.
Een melding dat er mogelijk gevaar is vind ik nog wel ok.

Toch wel een typische Apple manier van handelen die ik niet kan apprecieren.

Het is een lek dat inmiddels actief wordt gebruikt waardoor het risico ineens een stuk groter is. Apple heeft hier te maken met diverse gebruikers (niet alleen bedrijven!) en is vorig jaar ook al eens tegen dit soort praktijken aangelopen. Destijds kreeg men forse kritiek dat ze niet zo snel waren met blokkeren en daar hebben ze dus overduidelijk van geleerd.

Overigens is het updaten van de Xprotect settings ook maar heel betrekkelijk want het gaat alleen op voor wie Mountain Lion draait. Deze is in staat om dagelijks op updates te controleren. Voorgaande versies (de versie zoals we die nu kennen bestaat sinds Snow Leopard, in de voorganger Leopard zat eenzelfde mechanisme die veel overkomt met het huidige Xprotect) kunnen niet zo vaak op updates controleren. Het updaten is iets wat je in OS X uit kunt zetten. De file zoals in de screenshot van het artikel is aan te passen. Je kunt de Java entry verwijderen. Met andere woorden: systeembeheerders en gebruikers hebben dus wel degelijk een mogelijkheid om te beslissen wat er geblokkeerd wordt. Het enige probleem is dat het geen voor de hand liggende methode is. Voor systeembeheerders is dat niet erg, het is in zere zin zelfs prettig omdat users niet zelf in staat zijn om security zaken te omzeilen. Bij wat Firefox en Chrome doen loop je het risico dat een user altijd op "enable" klikt waardoor je een schijnveiligheid hebt. De drempel om system files te bewerken is te hoog en met goed ingestelde rechten ook niet mogelijk. De beheerder bepaald dan voor de gebruiker.

vorige keer was de kritiek vooral aanwezig omdat Apple zelf instaat voor de verdeling van java en maanden gewacht had met het uitbrengen van een patch. Terwijl alle andere OSen al veilig waren werd het lek toen ook actief misbruikt en in plaats van het lek te dichten ging men het probleem minimaliseren.

Ja, je kan de java enttry gaan verwijderen, maar dan moet je eerst al weten wat er mis is (geen communicatie vanuit Apple) en in een bedrijfsomgeving zou het betekenen dat je elk systeem 1 voor 1 zult moeten afgaan omdat je als sysadmin het niet kunt wijzigen voor iedereen.

Dat maanden wachten is niet helemaal waar. Oracle wachtte een paar maanden omdat ze het mee wilden nemen met hun patchronde ipv voortijdig vrijgeven en dat lijkt nu weer te gebeuren. Helaas heeft Apple toen de fout gemaakt om er zelf ook 2 maanden mee te wachten en dat is ze inderdaad terecht verweten. Het is echter niet zo dat Apple er maanden mee heeft gewacht, dat zinspeelt op een getal dat veel hoger ligt dan 2 (dan denk je eerder aan 6 maanden). Daarbij zinspeel je dus ook geheel ten onrechte op het meer secure zijn van andere operating systems. Zoals gezegd heeft Oracle het lek een aantal maanden open gelaten en waren andere OS's dus zeer zeker niet veiliger.

Daarnaast was het algemene advies destijds dezelfde als nu: disable Java. Daarmee ligt de onveiligheid van het OS daar waar hij altijd al ligt: bij de gebruiker.

Er was verder ook niks mis met de nieuwsvoorziening omtrent het probleem want je werd er mee doodgegooid. Je ovedrijft hier dus schromelijk.

Dan enable je de plugin toch weer?

Ik laat het liever gebeuren, dan kan ik me op mijn werk blijven concentreren! Als ik het nodig heb, zet ik het wel weer aan, want dat kan natuurlijk gewoon nog.
Niks is erger dan me werk te moeten onderbreken omdat ik system operator moet worden voor een tijd.

Gezien de ernst is het het beste om het standaard uit te zetten zoals Apple doet. Ik heb veel kritiek op Apple, maar dit doen ze goed.

Op deze manier ligt de verantwoordelijkheid bij de gebruiker om het weer aan te zetten (en het systeem daarmee onveilig te maken). Een systeem moet "secure by default zijn" (mede ook het credo van het OpenBSD systeem) dwz standaard veilig.

En het is ook logisch dat een systeem standaard doet wat de massa beliefd maar aan is te passen door experts. Voor experts is het weer aanzetten van Java een kat in het bakkie. De workaround is ontzettend eenvoudig, hoef je geen XML expert of kernel ontwikkelaar voor te zijn. Je hebt root en een text editor nodig. Als je dat niet zelf uit kunt vogelen geen probleem maar dan lijkt het me verstandig dat je het laat zoals het is.

dat doe ik liever zelf

Wel, jij als kundige tweaker kan het zelf natuurlijk weer aanzetten.

Maar Apple heeft hiermee verstandig actie ondernomen op een mogelijk groot probleem. Zeker voor Apple die hun gebruikers veel van het onderhoud uit handen wil nemen is dit een te verwachte en correcte stap.

Ja inderdaad.
+1 van mij

Ze nemen inderdaad maatregelen maar ze mogen de gebruikers wel op de hoogte stellen dat ze De Java plugin uitschakelen.
Zo zat ik gisteren toch wel even te vloeken waarom de Java plugin in onze software in safari niet meer werkte zoals in mijn http://gathering.tweakers.net/forum/list_messages/1533012 forumpost.

Mja.. en weer gaat het net als met Flash om een externe partij en weer zijn mensen de dupe van een techniek welke door het halve internet wordt gebruikt. Je kunt denk ik ook andere wegen verzinnen om dit soort dingen klantvriendelijker aan te pakken.

Er is anno 2013 bijna geen website meer in de lucht die afhankelijk is van clientside Java, hoor.

Serverside wordt het veel gebruikt, maar daar heb je als gebruiker niks mee te maken. Verder wordt Javascript natuurlijk wel veel gebruikt, maar dat is heel wat anders dan waar het hier om gaat. Echte Java applets op websites kom je nauwelijks meer tegen vandaag de dag.

Ticketpoint

Al die arme Mac gebruikers kunnen nu geen tickets bestellen voor de Toppers...

Of, Ticketpoint kan Mac gebruikers niet meer bedienen omdat ze van Java afhankelijk zijn. Wat ik bedoel te zeggen is het is in belang van beide partijen dat dit goed werkt.

Consumenten websites niet nee, maar in het bedrijfslevens zijn er zat java gebaseerde web applicaties die dan wel op het internet of op het intranet draaien.

Erg vervelend als je perongeluk deze update uitrolt voor je mac users en ze opeens geen gebruik meer kunnen maken van alle web applicaties.

Als een beetje goede sysadmin rol je dan ook niet klakkeloos updates uit

Ik gebruik ChromeOS al anderhalf jaar. En Java heeft nooit onderdeel uitgemaakt van dit OS. En heb het nog nooit gemist op geen enkele website die er tegenwoordig nog toe doet.

Dus het halve internet is redelijk zwaar overdreven.

Het halve internet draait er op, serverside

Geldt dus wel voor Flash..

Bijzonder hoe men restricities goed durft te praten. Dat is het namelijk niet.

De meest slechte software plugin bouwen (waar 50% van de malware zich op richt), waarvoor afgelopen jaar gigantisch veel veiligheidslekken zijn gevonden is natuurlijk wel goed. Die software vervolgens om de 3 maanden patchen of sommige lekken zelfs nog later oplossen is nog veel beter.

Het wordt amper gebruikt door doorsnee gebruikers en deze weten vaak niet eens wat Java is.

Een virus die persoonlijke gegevens of geld van je bank steelt is inderdaad beter dan de plugin tijdelijk uitschakelen.

Onze bedrijfssoftware van de ING heeft zelfs Java nodig om te werken... Nooit begrepen.

Even voor alle duidelijk, het gaat hier om een Java plugin die het mogelijk maakt Java Applets (kleine java apps) te kunnen draaien in een browser. Dit is iets wat niet veel meer gebruikt wordt. Vandaar dat het uitschakelen van de browser plugin een prima oplossing is. Java wordt verder in een zeer groot aantal web en applicatie servers gebruikt, evenals in sommige client applicatie(s) en daar is NIETS mis mee. Het probleem zit 'm dus alleen in de applets.
Enige nuance in dit geval zou dus wel op z'n plaats zijn.

Onze bedrijfssoftware van de ING heeft zelfs Java nodig om te werken... Nooit begrepen.

Alsof in andere programmeertalen geen (beveiligings)lekken kúnnen zitten. Ligt ook echt maar net aan de kwaliteit van het programeren. Er zijn dus 2 factors hier eigenlijk. Enerzijds de maintainer van de programmeertaal (Oracle in het geval van Java) en de programmeur(s) van de applicatie.

Ik ken persoonlijk geen software van de ING die java gebruikt.

Echter, ik verkies java wel boven activex. Cross-platform nl. Er is geen alternatief als het echt code moet draaien (als in niet in html/javascript/<friggin' flash - net zo erg, maar zelfde verhaal>/etc. kan).

Nou draai ik geen windows (en dus geen IE), dus heb weinig te kiezen .

ik wel

Als je als tweaker betere ideeen hebt over hoe het dan wel moet kun je dat natuurlijk altijd bij je werkgever op applicatiebeheerder aangeven. Kunnen ze meteen aangeven waarom je dat niet begrijpt indien ze gelijk hebben vanwege kosten bijvoorbeeld.

Ja, die zelfde software die Apple vroeger standaard meeleverde en die onder os X standaard maanden later een update kreeg en daardoor vele onveilige bugs achterliep.

Ben benieuwd wat ze doen als er een bug in osX wordt gevonden. Zouden ze dan tijdelijk heel osX plat leggen totdat de gebruiker de update heeft toegepast?

Java applets zijn ook niet meer van deze tijd, het heeft praktisch alle nadelen van Flash maar werkt VEEL slechter. Het is een plugin, maar werkt vaak maar in 1 browser, en 9 van de 10 keer laden de applets helemaal niet. Java is voor de desktop, niet voor het web.

Java op zich is een enorm fijne en krachtige programmeertaal (kwaliteit en snelheid is ongeveer hetzelfde als .NET applicaties). Het is alleen jammer dat het vaak in slecht licht komt door dit soort veiligheidslekken..

En het is niet meer dan terecht dat het zo vaak slecht in het nieuws komt. Ik loop inmiddels met een grote boog om Java heen en als ik een leverancier hoor welke een Java based applicatie uitbrengt dan gaan bij mij de nek haren overeind.
Het probleem is niet alleen de security, maar ook de compatibiliteit.
Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.
Backwards compatibiliteit is zelfs bij minor updates niet gegarandeerd.
In potentie zal het allemaal best wel mooi en goed zijn. Praktijk leert dat het een zorgenkindje is.

Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.

Ik denk dat dit wel meevalt.Bij applicaties die ik ken die gebruik maken van Java functionaliteit wordt een compatibele versie van de java runtime environment (JRE) lokaal meegeïnstalleerd. De software refereert bij zijn functioneren dus alleen aan deze lokale java installatie. Deze lokale Java gaat niet mee in de update van de java RTE waarhet OS aan refereert. Pas wanneer de software zelf een update ondergaat, wordt ook weer een bijbehorende recentere Java RTE meegeïnstalleerd.

Is dit een charmante oplossing? Nou nee. Al die Java RTE versies verdienen geen schoonheidsprijs. De softwarebouwer houdt zo wel regie over de eigen environment. Het betekend echter ook dat de softwarebouwer zich hiermee verantwoordelijk maakt voor het gebruik van die verouderende Java RTE. Dat is een afweging voor de softwarebouwer.

Edit:
In reactie op JUDGExKTF

Als je een leverancier hebt welke zegt je moet op Java 1.4 blijven zitten want anders werkt het niet kan je die meteen een etiket met "incompetent" erop op ze voorhoofd plakken.

Zoals je hierboven kan lezen zit ik daar wat diplomatieker in. Zolang de software leverancier zich verantwoordelijk stelt voor de veiligheid van zijn software, is een lokale installatie een invalshoek. Blijkbaar heeft ook deze softwarebouwer problemen gekregen met veranderende Java versies, dat ze dit is gaan doen. Ik gaan geen namen noemen, maar de bouwer is geen kleintje. Over de programmeerkwaliteit van de software kan ik geen oordeel geven. Blijkbaar is de werkelijkheid wat genuanceerder dan je hierboven stelt.

[Reactie gewijzigd door teacup op 12 januari 2013 14:55]

Zolang de software leverancier zich verantwoordelijk stelt voor de veiligheid van zijn software, is een lokale installatie een invalshoek.

Helaas kan de software leverancier geen beveiligings gaten patchen in de officiele Sun / Oracle JRE. Lokale installatie of niet, je installatie is dan dus kwetsbaar. Dus ondanks dat hij er zegt voor garant te staan kan hij er in technische zin niet garant voor staan. In theorie zou hij zelf een build van OpenJDK kunnen leveren welke hij getest heeft met zijn software en daarin tevens alle security fixes stopt. Op die manier kan je tot in de oneindigheid Java 1.4 veilig in de lucht houden.

Ik gaan geen namen noemen, maar de bouwer is geen kleintje.

Ik weet uiteraard niet wie jij bedoelt maar ik kan denk ik een grotere naam noemen: Cisco. Cisco heeft er een handje van om specifieke versies van JRE's voor te schrijven. Dit deden ze bijvoorbeeld bij de SDM. Deze GUI applicatie werkte heel lang enkel met Java 5. Geen idee hoe dat nu is overigens, wellicht hebben ze daar verandering in gebracht.

Over de programmeerkwaliteit van de software kan ik geen oordeel geven. Blijkbaar is de werkelijkheid wat genuanceerder dan je hierboven stelt. Blijkbaar heeft ook deze softwarebouwer problemen gekregen met veranderende Java versies,

De discussie ging erover of je Java dit kan aanrekenen. Als deze partij de software in .Net had gemaakt had dat waarschijnlijk geen verschil uitgemaakt. Aangezien als deze partij zich gewoon gehouden had aan de regels er geen probleem was geweest. Aangezien ze dat niet doen maakt de taal / framework waarschijnlijk weinig verschil.

Ik heb zelf legio software geschreven en ontwerpen (veelal in Java) en ik heb nooit deze problemen gehad. Ik weet echter dat het heel aanlokkelijk kan zijn om "afstekertjes" te nemen tijdens het programmeren welke later slecht kunnen uitpakken (en resulteren in boven beschreven incompatibiliteit). Bijvoorbeeld wat doe je in Java als je iets Base64 moet encoden; Pak je even snel de Base64 encoder uit "com.sun"? Of pak je een opensource implementatie? Als je de implementatie uit "com.sun" pakt dan weet je dat dit vroeg of laat problemen kan gaan geven (en je moet het weten want de compiler waarschuwt je).

Nogmaals, ik ben geen programmeur. Wel denk ik je beschrijving over de "afstekertjes" te kunnen herkennen (prachtig omschreven trouwens). Daar ik de software al een tijdje meemaak herken ik regressieproblemen, versies die niet kunnen wat voorgaande versies wel konden. Bij een volgende update is die functionaliteit weer hersteld. Kijkend naar de software als een systeem, dan is de software die ik bedoel nerveus geregeld. Die nervositeit kan daar ontstaan waar de bouwer zelf geen invloed op heeft. Dit kan je dan weer lezen als een "zie je wel, Java is dus de oorzaak". En ik moet zeggen, de klantencommunity is de afgelopen jaren ruimhartig in die conclusie gesprongen. Een van de andere mogelijke oorzaken zijn de door jouw genoemde afstekertjes, want als juist de Interface, waarmee de software afhankelijk is van zijn omgeving, rommelig is geprogrammeerd kan ik me levendig voorstellen dat er voortdurend bonje is met het toepassen van Java routines.

De discussie ging erover of je Java dit kan aanrekenen. Als deze partij de software in .Net had gemaakt had dat waarschijnlijk geen verschil uitgemaakt.

Dit vind ik dus een eye-opener, in je eerdere post al uitgesproken maar juist deze zin zet me aan het denken. Als ik de emotie van klantencommunity beschrijf dan is ze zoiets als: "beweeg weg van Java en naar .NET, want met Java hebben we negatieve ervaringen, en het Windows is het meest gebruikte OS".

Na de bovenstaande discussie draait mijn vizier nadrukkelijk weg bij de Java, en meer richting softwarebouwer. Naast dit Java interface aspect heb ik daar zonder programmeerkennis ook genoeg redenen voor. De programmeer rommeligheid lekt namelijk ook door de functionaliteit naar buiten. Hoofdverdachte wordt dan het change management van de bouwer. Die conclusie heb ik het afgelopen jaar, los van deze draad al getrokken en zie ik nu versterkt.

Wordt dit off-topic? Op kwade intenties zullen applicatiebouwers niet snel betrapt kunnen worden. Op rommelig programmeren zijn zijn zowel de applet als de applicatiebouwers te betrappen. Maar daar gaat deze draad niet over. Een vraag die ik nog niet gesteld heb zien worden is of het een gelukkige keuze is om twee onafhankelijke Java engines (plugin in browser en JRE in OS) op een computer te hebben. De afzonderlijke lokale JRE's van applicatiebouwers worden als not done beschouwd. Waarom is de browser plugin dan wel een geaccepteerd verschijnsel? Iedere browser zijn eigen plugin??? Is dat geen analogie aan die lokale applicatie JRE?

Voor mijn laatste vraag is de topic al best wel oud aan het worden. Weten meer Tweakers van dit soort lokale Java implementaties met een oudere time stamp Het veiligheidsrisico dat JUDGExKTF noemt maakt deze vraag relevant, ofschoon niet geheel on-topic, verteld het wel iets over de programmeer etiquette bij onze software leveranciers, en daar horen de browsers volgens mij ook bij.

Sorry hoor, maar dat is flinke onzin. Backwards compatibiliteit van Java is zo extreem hoog dat het bijna vervelend is. Het is het 'nieuwe Cobol' waar het gaat om een strategisch platform te bieden. Wat jij signaleert is dat we inmiddels veelal in de 2e of hogere generatie Java programmeurs beland zijn die nu de, inmiddels legacy, systemen mogen onderhouden. Dit is voor ieder technisch platform een flink uitdaging en leidt tot de menselijke reactie om er maar vanaf te blijven. Ik heb menig upgrade/conversie traject voor klanten mogen doen en in een hele kleine minderheid van de gevallen was er sprake van een technische reden waarom de upgrade lastig was. En in alle gevallen waar dit het geval was waren het programmeurs die 'creatief' hadden zitten doen (afhankelijkheden op een specifieke applicatie server, de ordening van de VM voor entries in een HashMap en meer van soort domme dingen).

Het probleem is niet alleen de security,

Wat is dan het fundamentele probleem van Java ten opzichte van bijvoorbeeld applicaties gemaakt in .Net, C, C++, PHP, Ruby? Alle software heeft gaten en Java ook.

maar ook de compatibiliteit. Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.
Backwards compatibiliteit is zelfs bij minor updates niet gegarandeerd.

"Don't shoot the messenger" ?

Dat heeft helemaal niks met de taal (Java) of de default Java VM implementatie (Hotspot) te maken. Dat heeft te maken met programmeurs en bedrijven die rotzooi uit private API van bijvoorbeeld "com.sun" gebruiken. De compiler geeft zelfs warnings en errors als je dat doet. Tevens word het binnen de gemeenschap gezien als extreem bad practice. Java 7 kan prima Java 1.3 gecompilde applicaties draaien, zonder enig verschil. Als je een leverancier hebt welke zegt je moet op Java 1.4 blijven zitten want anders werkt het niet kan je die meteen een etiket met "incompetent" erop op ze voorhoofd plakken.

Java is juist extreem compatible. Software draait op verschillende implementaties van Java zonder recompilen out of the box; Hotspot, IBM Blackdown, BEA Webrockit en dan ook nog op verschillende platformen; Linux, Windows, FreeBSD, Solaris, etc.

In potentie zal het allemaal best wel mooi en goed zijn. Praktijk leert dat het een zorgenkindje is.

Ik loop inmiddels met een grote boog om Java heen en als ik een leverancier hoor welke een Java based applicatie uitbrengt dan gaan bij mij de nek haren overeind.

Voor iemand bij wie er in zijn profiel staat "IT Project Manager" vind ik dit allemaal wel erg kort door de bocht en kort zichtig. Je komt gaat zeker ook nooit meer naar je Turkse bakker om de hoek, hoe goed het brood wellicht ook is?

Met lokale Java applicaties is niets mis, ik (en het artikel ook) heb het over de web applets. Dat zijn onveilige rotdingen, het is net ActiveX.

In principe niet minder onveilig dan Javascript, Silverlight en Flash - het hele principe van het huidige web dat je zo maar code van elke willekeurige website kan uitvoeren is fundamenteel onveilig. Wil je daar van af, dan moet je weer naar een web van puur statische HTML gaan, maar die geest kan allang niet meer terug de fles in.

Terecht dat Dreamvoid en jijzelf dit nog eens onderstrepen. Uit andere reacties in de draad blijkt dat meer gebruikers over deze "subtiliteit" heenstappen. Beseffende dat ik deze nuance ook miste ben ik even in een (stoffig) schoolbankje gekropen voor mijn eigen referentiekader (onder het mom van: "een Tweaker die zijn onkunde niet durft te erkennen is geen echte Tweaker":

Like applications, applets are created from classes. However, applets do not have a main method as an entry point, have several methods to control specific aspects of applet execution, and while applications run in the Java VM installed on a computer system, applets run in the Java VM installed in a web browser. You can also run an applet in a special tool for testing applets called applet viewer.

De werkelijkheid die ik uit het bovenstaande en de Wiki's voor Java applet en Java Virtual machine opbouw is dat zowel vanuit de Java plugin in de webbrowser, getriggerd door een Java applet in een webpage als vanuit de Java RuntimeEnvironment, getriggerd door een Java applicatie, een Java Virtual machine wordt gestart waarin de Java commando's worden uitgevoerd.

Om het ten aanzien van het bovenstaande een beetje aan te scherpen: de web applets geven de stoute opdrachten, maar het is de brouwser-plugin die de uitvoer toelaat. Wat mij betreft zijn de plugins in dit geval de onveilige rotdingen die de rottigheid van het internet zonder pardon uitvoeren.

Zo heeft ieder windows systeem minimaal twee Java implementaties, een voor de browser (plugin) en een voor het OS(JRE). Met een beetje pech komen daar nog een of meer toepassingsspecifieke JRE's bij met een verouderde versie time stamp als een soort safe haven. Ondanks alle rafels blijft Java als een van de weinige echt multiplatform van opzet. Dat dit een groot goed is blijkt wel uit het feit dat Microsoft dit gegeven met een .net implementatie op het Linux platform tracht te counteren. Los van dit ben het ook erg eens met de opmerking van Dreamvoid hierboven dat het actief maken van web pages een de brede zin van het woord de deur voor misbruik openzet. Misschien zijn actieve web pages toch een naïef idee dat tegen de harde werkelijkheid van onze maatschappij aanbotst.

[Reactie gewijzigd door teacup op 13 januari 2013 00:34]

We hebben het hier over de Java plugin die remote code draait, niet over lokale applicaties.

Bijzonder. Ook vreemd dat Apple hier geen bericht van maakt, terwijl het toch wel wat is om Java af te sluiten voor je gebruikers.

Java wordt dan ook niet afgesloten, de browser plug-in wordt uitgeschakeld.

Da's toch kwalijk. Een boel sites gebruiken Java..

Op een bedrijfsintranet misschien maar in de praktijk komt het voor gewone gebruikers nauwelijks meer voor.

Dit is idd wel een lastige zaak. gaat Apple in de toekomst ook bij elke Chrome of Firefox exploit de 3rd party browsers blokkeren?

Je moet het natuurlijk wel een beetje in perspectief zien. Het gaat hier om de ernst van de lek en of deze al actief wordt misbruikt. Bij deze Java exploit is dat het geval.
Tevens is denk ik de impact minder groot vele mensen die Java geïnstalleerd hebben staan, zijn er niet eens bewust van dat er een browser plugin geïnstalleerd is en dat deze aan staat. De grote groep zal er ook geen gebruik van maken.
Neemt niet weg dat dit iets is wat men beperken communiceren, maarja hoe?
Uitschakelen van apps is van heel andere orde, die worden waarschijnlijk bewust en actief gebruikt.
Het blijft moeilijk, waar ligt de grens.

Er zijn bakken met exploita voor oude Firefox versies, maar toch mag je die gewoon nog draaien. Maar goed, aangezien Apple zelf medeverantwoordelijk is voor lekken in Java (ze zijn mede-ontwikkelaar) is het begrijpelijk dat ze wat actiever actie ondernemen dan bij pure 3rd party software.

Apple ontwikkelde eerst inderdaad een eigen JRE voor OSX (welke bij default werd meegeleverd). Maar dat is sinds Lion oid niet meer het geval. Nu moet een persoon zelf dus eerst Java installeren en downloaden bij Oracle weg voordat de persoon Java heeft.

Apple ontwikkelt nog steeds aan de JRE, ze zijn lid van het OpenJDK project en werken onder supervisie van Oracle aan de OSX versie van Java.

Waarom niet gewoon auto execute van java applets afzetten? Dan heeft de gebruiker zelf de keuze en als hij/zij een applet wilt gebruiken gewoon een melding geven van: "dit kan mogelijk onveilig zijn vertrouwd u de maker van deze applet?". Gebruiksvriendelijk en zonder dat mensen zonder technologische achtergrond zich gaan afvragen waarom bv hun bank applet niet meer werkt.

De vraag is dan wel waar dat eindigt: moet je dan ook bij elk blokje Flash, Silverlight of Javascript code een popup tonen? Dan kom je niet meer aan browsen toe, bijna geen enkele site draait meer op puur statische HTML.

[Reactie gewijzigd door Dreamvoid op 12 januari 2013 13:10]

Ja maar het lijkt mij een betere manier dan het gewoon uit te zetten. Moet er niet iets in de configfile worden aangepast als je snel 1 applet wil gebruiken. Ik doelde ook meer op een klik to activate systeem.

Daarbij het gros van de users klikt toch wel ok...

OpenJDK is een open source project, is de bug al gefixed of alleen de officiele Oracle release nog niet?

Maar Java heeft idd niet zoveel zin meer als browser plugin, wie gebruikt er nog applets anno 2013? Laat Java lekker serverside, daar is het goed in.

[Reactie gewijzigd door Dreamvoid op 12 januari 2013 12:22]

Ik vermoed dat de bug met de Java plug-in/VM zelf te maken heeft, dus ik verwacht dan ook dat OpenJDK mogelijk wel veilig is (tenzij OpenJDK er zelf ook op deze manier mee om gaat, waardoor ze allebei onveilig zijn). Even googlen op een eventuele update hierover voor OpenJDK zou ik zeggen

EDIT: foutje verbeterd wat Dreamvoid onder mij noemde

[Reactie gewijzigd door Cheap Apps op 12 januari 2013 12:31]

'De Java applet' bestaan niet, er zijn duizenden applets op het web.

wat doen mensen die minecraft ofzo willen spelen op hun mac?

Getest en werkt gewoon. Ik weet niet hoe het precies zit, maar zal iets te maken hebben met het feit dat Javascript IN het programma zit ofzo?

Javascript IS GEEN java. Het gaat hier om java iets dat sommige webapplicaties en ook minecraft gebruiken (en nog veel meer apparaten). Ik weet niet zeker hoe het zit maar volgens mij gaat het hier vooral om de safari plugin die geblokkeert is. Java programmas die dus zonder browser gebruikt worden zouden dan geen last hebben van de blokkade, minecraft hoort bij de programmas die zonder browser draaien.

Ik heb geen mac (os) om dit te testen en controleren en dat zal voorlopig ook zo blijven. Dit is namelijk een van de vele redenen om geen apple te willen als computer. Ik wil nog altijd wel even zelf bepalen wat ik kan mag en doe op mijn pc. Of er nou een beveiligingsprobleem is of niet. Apple schijnt daar altijd problemen mee te hebben en wilt dat graag zelf bepalen voor de consument. Als het nu alleen een waarschuwing was geweest en de klant de keus kreeg om java te blokkeren of niet dan was het goed van ze maar ze schieten te ver door.

Goed dat het kan - maar hoe komt het dat de gebruikers dat niet zelf kunnen opheffen indien nodig/nuttig/wenselijk?
Apple = een totalitair bedrijf - een bedrijf waarvan je de hard en software eigenlijk in een bedrijf niet kan inzetten.
Stel dat uw VPN-oplossing werkt met Java dan ben je door die setting van Apple gef*ck*d.

Het bewijst het nogmaals - geen enkel bedrijf is te vertrouwen als het er op aan komt moet de staat deze zaken "strak regelen".

Ik denk dat je het prima kunt opheffen, door dat versienummer weer te veranderen.