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)
Apple neemt in ieder geval maatregelen tegen het java lek.
dat doe ik liever zelf
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
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 zaterdag 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...
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.
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.
dus goed en fout is relatief.
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 zaterdag 12 januari 2013 19:40]
Die versie bestaat nog niet.
Dus ze zijn inderdaad niet meer kwetsbaar, maar je kan ook niets!Daarin wordt een Java-versie vereist die nog niet bestaat, waardoor effectief bestaande Java-plugins worden geblokkeerd.
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.
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.
Zeker bij OSX, wat juist mensen aan spreekt die verre van Tweakers zijn heeft Apple een zorgplicht. Die voeren ze hier uit.
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.
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]
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.
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.
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.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...
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.
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.
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 gewoon niet aan apple om simpelweg wel even te bepalen wat je wel en niet mag draaien op je mac
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
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.
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.
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)
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.
.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.
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.
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.
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.
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.
Bij OS X kan je Xprotect via MCX beheren, zoals dat hoort bij enterprise clients.
Dan enable je de plugin toch weer?
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.
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.
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.
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.
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.
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.
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.
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.
Ja inderdaad.
+1 van mij
+1 van mij
Wel, jij als kundige tweaker kan het zelf natuurlijk weer aanzetten.dat doe ik liever zelf
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.
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.
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.
Dus het halve internet is redelijk zwaar overdreven.
Het halve internet draait er op, serverside
Geldt dus wel voor Flash..
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.
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.
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.
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
Ticketpoint
Al die arme Mac gebruikers kunnen nu geen tickets bestellen voor de Toppers...
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.
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.
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.
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.Onze bedrijfssoftware van de ING heeft zelfs Java nodig om te werken... Nooit begrepen.
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.
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
.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.
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.
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?
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?
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 zaterdag 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.
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]
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.
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.
Je kunt ze geen ongelijk gegeven natuurlijk, nu maar hopen dat er wel een oplossing komt op korte termijn. Het is wel erg resoluut, gewoon boem de deur dicht. Om nou meteen alle java plugins te verwijderen 
.
.
Zo te zien is het nog handmatig te ontlopen lijkt me, voer gewoon weer een lager versienummer in en het is gefixt. Ik vind het overigens een erg goed systeem dat het zo snel geblokkeerd kan worden door Apple. Toch zou ik liever zien (voor beheerders in ieder geval) dat je een melding krijgt met dit en dat, met daarbij de keuze van blokkeren of niet. Desalniettemin goed gehandeld.
EDIT: Daarnaast vind ik het ook een goede zet om Java standaard uit 10.7 te halen. Vrijwel alle veiligheidsproblemen zijn via Java te vinden. Voor mij al een reden waarom ik het het liefste niet gebruik.
EDIT: Daarnaast vind ik het ook een goede zet om Java standaard uit 10.7 te halen. Vrijwel alle veiligheidsproblemen zijn via Java te vinden. Voor mij al een reden waarom ik het het liefste niet gebruik.
[Reactie gewijzigd door Cheap Apps op zaterdag 12 januari 2013 12:21]
Deze keer verwijdert Apple geen java plugins. De enige keer dat Apple dat wel deed verwijderde ze de javaplugin die door Apple gemaakt werd en dat was in de tijd dat het beheer van de OSX java versie werd overgedragen aan Oracle. De oracle javaplugin wordt niet verwijderd. Hij wordt wel uitgezet op deze manier.
De Java 6 client wordt nog steeds door Apple beheerd, en Apple schrijft ook nog steeds code voor de Java 7 client (onder beheer van Oracle) en zitten in het OpenJDK project dus ze kunnen niet alleen maar naar Oracle wijzen, ze moeten er zelf ook wat aan doen.
[Reactie gewijzigd door Dreamvoid op zaterdag 12 januari 2013 12:47]
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.
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 zaterdag 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
EDIT: foutje verbeterd wat Dreamvoid onder mij noemde
[Reactie gewijzigd door Cheap Apps op zaterdag 12 januari 2013 12:31]
'De Java applet' bestaan niet, er zijn duizenden applets op het web.
Bijzonder. Ook vreemd dat Apple hier geen bericht van maakt, terwijl het toch wel wat is om Java af te sluiten voor je gebruikers.
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.
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.
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.
Zo te zien alleen met de applet plugin. Daar ben ik blij mee want dat betekent dus waarschijnlijk dat je het alleen niet in je browser gebruiken kan ( bij mij staat hij sowieso al uit.. maar goed ) en ik toch gewoon nog de java apps die ik heb gebruiken kan ( intelliJ en zo ).
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.
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.
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.
Het is toch wel apart dat als Apple zelf een security issue heeft men het bagetaliseert of ontkent om dan weken later te fixen en als een ander een probleem heeft gaat men pro-actief doen. Dankjewel Apple, welkom in de club van de grote hypocriete bedrijven.
Dat is natuurlijk flauwekul wat je zegt. Deze lek is zodanig ernstig dat je mag verwachten dat er maatregelen worden genomen. Omdat men in het verleden niet altijd niet juist gereageerd heeft is dat geen reden om dan niet meer te verbeteren. Je mag er toch van uitgaan dat security inmiddels hoger op de agenda staat, gezien de maatregelen die men in mountain Lion op gebied van security heeft genomen, waarbij sommige onderdelen ook aan Lion zijn toegevoegd.
Men heeft nu een mechanisme in plaats om snel te kunnen reageren.
Tevens is wat hier gebeurt heel wat anders dan de update zelf uitrollen.
Men heeft nu een mechanisme in plaats om snel te kunnen reageren.
Tevens is wat hier gebeurt heel wat anders dan de update zelf uitrollen.
Ze hadden beter consistent kunnen zijn en gewoon het lek er moeten laten zitten? Je kan het hypocriet noemen, je kan het ook leren van je fouten noemen.
Ik snap de reacties, deels, wel: het zou inderdaad niet goed zijn als Apple niet leert van zijn fouten. Aan de andere kant zijn ze hier functionaliteit van derden aan het blokkeren omdat die niet veilig is. Stel je voor dat Firefox een bugje heeft en Microsoft via een Windows update Firefox disabled. Ik denk dat er dan heel wat meer mensen zouden zijn die roepen dat dit niet door de beugel kan. Het is een lastige vraag: waar begint en eindigt de verantwoordelijkheid van een leverancier. Met de history van Java op Mac in het achterhoofd (Java wat tot voor kort van Apple zelf, maar men vond het niet nodig het verder te supporten, dus mocht Oracle het zelf gaan doen) zou je ook kunnen redeneren Java, omdat het niet strategisch is voor Apple, zoveel mogelijk dwars gezeten moet worden om zo meer native code te krijgen voor het eigen platform.
Proportionaliteit telt ook mee, java wordt in de browsers nauwelijks meer gebruikt, in de uitzonderlijke gevallen dat je het nodig hebt kun je het weer aanzetten.
Ik ben overigens zelf ook niet zo happig op dit soort trucjes maar ik snap apple wel na alle foutieve berichtgeving over de " trojan" die via java 200k osx gebruikers had "besmet".
Ik had liever gezien dat ze mensen de keuze zouden hebben gelaten om java objecten te laden in een pagina.
Ik ben overigens zelf ook niet zo happig op dit soort trucjes maar ik snap apple wel na alle foutieve berichtgeving over de " trojan" die via java 200k osx gebruikers had "besmet".
Ik had liever gezien dat ze mensen de keuze zouden hebben gelaten om java objecten te laden in een pagina.
Het is niet helemaal 'een ander' Apple zit samen met Oracle, IBM, SAP in het Open JDK project. Oracle beheert het en brengt de officiele versies uit, maar Apple schrijft gewoon mee aan de Java client, en had deze bugs ook kunnen fixen als ze eerder ontdekt waren.
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".
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.
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.
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.
We hebben het hier over de Java plugin die remote code draait, niet over lokale applicaties.
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).
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.
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.
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".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.
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.
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":
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.
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.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.
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 zondag 13 januari 2013 00:34]
Leuk en aardig maar ik zie alleen maar stukje xml tags met wat waarden.
Zie nergens een bewijs van blokkade ...
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.
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 Sony Microsoft Games Politiek en recht Consoles
© 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
