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)
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.
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 zondag 13 januari 2013 22:35]
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.
Een waarschuwing zou wel op z'n plaats zijn vind ik.
Maar het gros van de PC en Mac gebruikers zegt zo'n waarschuwing helemaal niks. Dus je creeert alleen maar verwarring.
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.
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.
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.
Enige nuance in dit geval zou dus wel op z'n plaats zijn.
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 zaterdag 12 januari 2013 12:43]
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.
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 zaterdag 12 januari 2013 16:23]
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.
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.
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.
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.
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).
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.Het probleem is niet alleen de security,
"Don't shoot the messenger" ?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.
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.
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?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.
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.Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.
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
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.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.
[Reactie gewijzigd door teacup op zaterdag 12 januari 2013 14:55]
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.Zolang de software leverancier zich verantwoordelijk stelt voor de veiligheid van zijn software, is een lokale installatie een invalshoek.
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.Ik gaan geen namen noemen, maar de bouwer is geen kleintje.
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.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,
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).
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.
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):
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).
- /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
- /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
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 zaterdag 12 januari 2013 17:13]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
