Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Apple brengt binnenkort software-updates voor Spectre-kwetsbaarheid uit

Apple heeft zijn verklaring over de Meltdown- en Spectre-kwetsbaarheden online gezet. Het bedrijf bevestigt dat alle Mac- en iOS-apparaten getroffen zijn en zegt dat het al maatregelen tegen Meltdown heeft getroffen in zijn besturingssystemen. Binnenkort volgen updates tegen Spectre.

Volgens Apple zijn er nog geen exploits verschenen die Meltdown of Spectre inzetten bij aanvallen op Mac- of iOS-systemen. Exploits zouden veelal een kwaadaardige app vereisen die gebruikers dan zouden moeten installeren, dus Apple raadt aan alleen software vanuit betrouwbare bronnen zoals de App Store te installeren.

Apple heeft patches voor Meltdown doorgevoerd bij iOS 11.2, macOS 10.13.2 en tvOS 11.2, updates die in december uitkwamen. De Apple Watch is niet getroffen door Meltdown. Meltdown treft hoofdzakelijk Intel-processors, maar er is een kans dat de technieken ook in te zetten zijn voor processorarchitecturen van andere fabrikanten. Volgens Apple is er in ieder geval geen meetbare prestatievermindering bij macOS en iOS door de updates.

Volgens Apple is Spectre 'extreem moeilijk' te misbruiken, zelfs via kwaadaardige apps die lokaal draaien. Spectre treft zowel Intel- en AMD-processors als ARM-chips en is lastiger te patchen. Er bestaat de mogelijkheid dat aanvallen via Javascript op sites uit te voeren zijn. In de komende dagen brengt Apple daarom updates uit voor Safari om dit tegen te gaan. Bij de benchmarks Speedometer en ARES-6 ziet Apple geen impact op de prestaties, bij JetStream dalen de prestaties met maximaal 2,5 procent. Latere updates voor iOS, macOS, tvOS en watchOS moeten verdere patches tegen Spectre brengen.

Apple is een van vele bedrijven die klanten inlicht over de gevolgen van Meltdown en Spectre. Ook de chipbedrijven Intel, AMD en ARM doen dat, net als Microsoft met betrekking tot Azure, Amazon en Google.

Aangezien de kwetsbaarheden potentieel via Javascript misbruikt kunnen worden moeten browsermakers updates doorvoeren. Mozilla meldt eerste maatregelen doorgevoerd te hebben bij Firefox 57.0.4. Google neemt maatregelen in Chrome 64, die op 23 januari moet uitkomen. In de tussentijd kunnen Chrome-gebruikers site isolation inschakelen. Microsoft heeft Edge en Internet Explorer 11 bijgewerkt als onderdeel van Windows-beveiligingsupdate KB4056890.

Door Olaf van Miltenburg

Nieuwscoördinator

05-01-2018 • 10:40

92 Linkedin Google+

Submitter: T-Junkie

Reacties (92)

Wijzig sortering
Misschien een domme vraag, maar kunnen we javascript niet zien als onwenselijk op een systeem? Als een javascript zoveel privileges heeft of kan krijgen dan is dit toch eigenlijk al verkeerd geïmplementeerd? Of maw als ik Java volledig disable op mijn systeem heb ik dan nog steeds deze patches nodig? Nu worden er twee vulnerabilities gepatcht maar god weet wat er nog meer mogelijk is mbv een bepaald javascript.

edit: bedankt allemaal voor het reageren. Het is me duidelijk nu dat java en javascript verschillende dingen zijn en dat men er door de patches voor kiest om het dieper gelegen probleem aan te pakken. Sorry dat ik dat niet wist. Ik ben geen web developer.

[Reactie gewijzigd door InsanelyHack op 5 januari 2018 11:41]

Misschien een domme vraag, maar kunnen we javascript niet zien als onwenselijk op een systeem? Als een javascript zoveel privileges heeft of kan krijgen dan is dit toch eigenlijk al verkeerd geïmplementeerd? Of maw als ik Java volledig disable op mijn systeem heb ik dan nog steeds deze patches nodig? Nu worden er twee vulnerabilities gepatcht maar god weet wat er nog meer mogelijk is mbv een bepaald javascript.
Onterechte downmod imho.

Javascript is een risico, want je voert ongezien code uit die ergens op een website staat. Dat is normaal geen groot probleem, omdat die code in de browser in een sandbox draait, en maar heel weinig daar buiten kan doen. In dit geval is het mogelijk om geheugen te benaderen waar de sandbox (of enig ander user programma) geen toegang zou mogen hebben.
Dat ligt niet aan javascript, maar javascript is wel een heel handig middel om een exploit wijd te verspreiden. Het is nou eenmaal makkelijker mensen naar een web pagina te lokken dan ze een programma te laten installeren.
Javascript is een risico, want je voert ongezien code uit die ergens op een website staat. Dat is normaal geen groot probleem, omdat die code in de browser in een sandbox draait, en maar heel weinig daar buiten kan doen.
En dit is exact waarom er in mijn ogen een veel sterkere push moet komen naar een zoveel mogelijk JavaScript-vrij web. Het kan prima, de meeste functionaliteit is met de diverse dynamische elementen in HTML5/CSS prima te doen, dan doe je maar wat vaker een page reload en bouw je je HTML pagina serverside op. Security voor de gebruiker moet boven serverside een beetje data besparen staan.

Het hele security concept van JS in de browser gaat er nl van uit dat de browser sandbox perfect is - en de praktijk is al 25 jaar lang dat dit niet zo is. Dat was het ook niet bij de JVM van Java applets, dat was het niet bij Silverlight, dat was het niet bij de Flash runtime, en surprise surprise, in de JavaScript runtimes van Apple, Microsoft, Google en Mozilla ook niet. De IT business rolt telkens weer naar een nieuwe implementatie van hetzelfde fundamenteel risicovolle model ("draai ongezien willekeurige code van het internet en vertrouw op de sandbox"), maar "dit keer is de sandbox echt veilig".

Als je dan weer ziet dat een nieuwe generatie bedrijven druk bezig zijn om te heel hard te promoten dat JavaScript code via nog krachtigere/"rijkere" API's in de browser toegang moet krijgen tot de microfoon, de webcam, lokale storage, etc...echt |:( ik loop te lang rond in deze biz.

Ook van die hele kortzichtige euforie op Tweakers kreeg ik een totale facepalm: Hoera laten we Flash afschaffen, al die vervelende dynamische reclame banners met geluid en popovers, en allemaal zware client-side code. Oh ja, en weet je wat geweldig is? HTML5+JS, waarmee je nu nog 'rijkere' content mee kan maken zoals...dynamische reclame popover banners met geluid, en client-side cryptominers!

[Reactie gewijzigd door Dreamvoid op 5 januari 2018 17:28]

Javascript uitschakelen ga je niet lang volhouden omdat dan allerlei interessante interactieve websites en applicaties niet meer werken. In principe implementeert de browser een 'sandbox' waardoor scripts alleen binnen de geopende pagina werken, maar de broncode wordt tegenwoordig door een 'just in time' compiler naar native code omgezet en is daardoor gevoelig voor dit soort aanvallen. Dit is wel te patchen door browser bouwers waardoor het probleem niet meer te misbruiken is en je gewoon Javascript sites kan bezoeken.
Java is overigens een heel ander verhaal en heeft hier weinig mee te maken...
Zoals gezegd: Keypunchie in 'nieuws: Apple brengt binnenkort softwareupdates voor Spectre-k...

Je kunt plugins gebruiken om JavaScript selectief toe te laten. Dat kan al behoorlijk helpen.
Leuk voor techneuten, maar de grote massa gaat toch op 'toestaan' klikken omdat ze werkelijk geen idee hebben waarom ze het zouden moeten blokkeren. (en omdat de meeste pagina's tegenwoordig wel scripts hebben...)
Ik hoop dat dit een extra push is voor websites om HTML&CSS-only te gaan zonder JS. Het vasthouden aan JS is vooral luiheid en misplaatste zuinigheid, er is in 99% van de gevallen niks mis met een page reload.

[Reactie gewijzigd door Dreamvoid op 5 januari 2018 17:05]

Java en Javascript zijn 2 volledig seperate dingen.

Javascript heeft alleen zoveel privileges als dat de browser hem toekent. Het is dus aan de browser bouwers om dit juist te beperken.
Hoewel het klopt dat Java != JavaScript, staat je reactie eigenlijk los van de vraag van InsanelyHack.

Om JavaScript volledig te disablen kan InsanelyHack bijvoorbeeld NoScript gebruiken. Om Java volledig te disablen (in zijn web browser) kan hij bijvoorbeeld deze documentatie volgen.

Met zowel Java als JavaScript kan een Spectre-aanval uitgevoerd worden. M.a.w. moet je beiden uitschakelen wil je zeker zijn dat, wanneer je naar een website surft die je niet vertrouwt, met een browser die vandaag courant is, de Spectre bug niet tegen je gebruikt wordt. In het artikel staat welke browsers al en welke browsers wanneer zullen voorzien worden van maatregelen die ervoor zorgen dat een website het Spectre probleem niet kan misbruiken. Tot die tijd, en, tot wanneer je die upgrades hebt uitgevoerd, ben je niet veilig wanneer je JavaScripts toelaat.
Het ei dat ooit bedacht heeft dat Java en Javascript praktisch dezelfde naam moesten hebben zou een schop onder zijn kont moeten krijgen :(
Is de werkelijke naam ook niet ECMAScript?
Toen Netscape aan het werken aan een HTML script taal kregen ze een interne presentatie van het Sunteam dat aan Java aan het werken was. Ze waren zo onder de indruk van de mogelijkheden (en hun beperkingen) dat het Netscape team op de kar gesprongen is en een afgeleide naam gekozen hebben. En nu zitten we ermee :-(
Javascript heeft alleen zoveel privileges als dat de browser hem toekent. Het is dus aan de browser bouwers om dit juist te beperken.
Dit geldt natuurlijk ook voor Java - het heeft in theorie net zoveel privileges als de JVM hem toekent. Probleem in beide gevallen: die sandbox is niet perfect.

Java en JavaScript zijn inderdaad volledig verschillende talen en runtimes.

Java in de browser is anno 2017 vrijwel volledig van het internet verdwenen, en wordt alleen nog maar voor serverside code of in lokaal draaiende applicaties gebruikt, terwijl JavaScript in de browser runtime clientside wordt uitgevoerd, willekeurige code van het internet, en dat maakt het in deze situatie zo gevaarlijk - elke website die je bezoekt kan je ongezien aanvallen.

[Reactie gewijzigd door Dreamvoid op 5 januari 2018 17:14]

Java and Javascript are similar like Car and Carpet are similar

Javascript is niet iets wat je kan installeren, je krijgt het binnen via websites en is ondertussen niet meer weg te denken.
Bij de meeste browsers kun je javascript uitzetten, dan wordt dit helemaal niet meer uitgevoerd. Of de website dan nog naar behoren functioneert weet ik niet, mij lijkt van niet :)
Het valt soms mee, vaak tegen.

Zelf gebruik ik voor Firefox de plugin "Noscript":
https://addons.mozilla.org/en-US/firefox/addon/noscript/

Dankzij FF57 is hij wat minder gebruiksvriendelijk geworden dan voorheen, maar intussen is er een stabiele, bruikbare versie, met wat uitleg en weinig bugs.

En voor Chrome/Vivaldi is er : ScriptSafe
https://chrome.google.com/webstore/search/scriptsafe

Die laatste heb ik eigenlijk weinig ervaring mee, dus dat als waarschuwing.

Hoe deze plug-ins werken is dat je whitelists bijhoudt van welke sites/domeinen scripts mogen draaien. Je kunt ook tijdelijke toestemming geven aan een domein. Bij beide kun je ook instellen dat het domein dat je direct bezoekt altijd tijdelijke toestemming krijgt.

Mijn ervaring is dat met een handjevol whitelists en de instelling "domein dat je bezoek krijgt tijdelijke rechten" eigenlijk best goed kan surfen. En het scheelt een hele hoop advertenties/trackers/stiekeme-mining scripts.

Wel een waarschuwing: de eerste week of twee ben je nog wel aan het leren hoe de plug-ins werken en ook zul je voor de rest van je browsecarriere wel eens afvragen "waarom doet deze site zo raar" en dan "oh ja, gebruikt vast third-party scripts".

Mijn ervaring is dat de meeste e-commerce enzo het wel aardig doen, maar dat de meeste media-sites echt van de ranzige third-party scripts aan elkaar hangen. Aan de andere kant, ik heb dus nooit last van auto-playing video's, script pop-ups, ongewenste notificaties etc.

En het geeft een bepaalde mate van bescherming tegen Spectre. Elk script dat niet wordt uitgevoerd is weer een stukje 'attack surface' minder.

[Reactie gewijzigd door Keypunchie op 5 januari 2018 11:21]

Er is bijna geen website die echt fatsoenlijk functioneert zonder tegenwoordig.
Hier op tweakers is het redelijk OK (en ze gebruiken het dus best wel op een goeie manier op deze site) en werken er maar sommige dingen niet helemaal. Op veel websites is dat verhaal wel anders en is het gewoon praktisch onbruikbaar.
Er zijn hele platformen zoals SharePoint (in sommige opzichten) of Angular die echt per sé JS nodig hebben om überhaupt iets van een website te tonen.
Aantal jaar geleden proberen browsen zonder javascript, het was toen al niet te doen, het is er alvast niet op vooruit gegaan.
Ten eerste: java en javascript zijn twee compleet verschillende dingen!

Ten tweede, 10 jaar geleden had dat nog gekund, tegenwoordig kun je bijna niet meer zonder als je een beetje dynamische website wilt. Je kunt een heleboel javascript uitschaken, maar zeker niet alles.
Deze lekken zijn onder andere via javascript te misbruiken. Maar (bijna) iedere andere uitvoerbare code heeft de mogelijkheid om dit te doen. Dat het via javascript kan wordt vermeld omdat javascript via een site geladen kan worden, waar bij andere uitvoerbare code vaak een user-actie nodig is.
Geen domme vraag, die bestaan niet. Door sommige wordt JavaScript als onwenselijk gezien omdat het het "third party code" is, andere vinden het juist wenselijk omdat het vaak een verrijking voor de applicatie is (extra functionaliteit/gebruiksvriendelijkere technieken etc.).

Die discussie zelf is nu niet zo interessant, wel de informatie dat deze code in principe geen toegang heeft tot je systeem en beperkt is tot de sandbox van je browser. Het wordt alleen écht eng als JavaScript dingen kan doen buiten de bedoelde grenzen of als er andere wegen gevonden worden om het te misbruiken en dat lijkt nu te gebeuren.

Als ik het juiste lek in mn hoof heb zitten en het goed uitleg (correct me if i'm wrong) gaat het hier niet direct om het breken uit de sandbox. Maar kan door bepaald gedrag uit te voeren ergens een bit in geheugen aangetast raken middens een side effect. Het gaat dus niet om privileges maar om een error in het systeem en de mogelijkheid dat te gebruiken (exploit).

Hoe dit tot in detail werkt weet ik niet maar ik denk niet dat dit we dit op puur JavaScript moeten afschuiven. Er zijn wellicht vele andere mogelijkheden om dit te misbruiken alleen JavaScript is een belangrijke omdat dit doorgaans een makkelijk uit te voeren methode is. Het echte probleem zit veel dieper en daar dient (uiteindelijk) de oplossing gezocht worden. Tot die tijd is het natuurlijk wel wenselijk dat ook browsers hier een verdedigingsmuur opgooien.

[Reactie gewijzigd door Ed Vertijsment op 5 januari 2018 11:03]

Wat is het verschil tussen JavaScript en Java ?
De JavaScript-programmeertaal, ontwikkeld door Netscape, Inc. en maakt geen deel uit van het Java-platform. Met JavaScript kunnen geen applets of zelfstandige applicaties worden gemaakt. JavaScript wordt meestal gebruikt in HTML-documenten. Met JavaScript kan aan webpagina's een mate van interactiviteit worden toegevoegd die gewoonlijk niet met eenvoudige HTML kan worden gerealiseerd.

Belangrijkste verschillen tussen Java and JavaScript:
-Java is een OOP-programmeertaal terwijl JavaScript een OOP-scripttaal is.
-Met Java worden applicaties gemaakt die in een virtuele machine kunnen worden uitgevoerd. JavaScript-code kan alleen in een browser worden uitgevoerd.
-Java-code moet worden gecompileerd, terwijl JavaScript-code enkel uit tekst bestaat.
-Voor beide zijn andere plug-ins nodig.

En voor nog meer info kun je hier terecht:
klik = Java Help Center
Welke van die twee had lang geleden een logo met een kop koffie?
Java, dat heeft ie nog steeds https://java.com
Java, en heeft dat nu nog steeds ;)
Met JavaScript kunnen geen applets of zelfstandige applicaties worden gemaakt.
Vertel dat aan Microsoft en Google, die zetten enorm in op JS om native apps te maken :)
Heb je zo een voorbeeldje, heb net even lopen zoeken namelijk, en kon er zo even niet zo snel een vinden, maar dat het gebeurt klopt inderdaad.

Minecraft werkt op Java inderdaad, dat heb je goed, en dus geen JavaScript.
Maar heb hier inmiddels zo veel lopen posten vandaag dat ik een beetje in de war aan het raken ben nu volgens mij, en nu zelf zelfs beiden door elkaar begin te halen, niet echt handig dus zeg maar 8)7

Ik laat het hier dan ook bij voor vandaag, maar ben er serieus wel benieuwd naar, dus let me know, alvast bij voorbaat dank.

[Reactie gewijzigd door SSDtje op 5 januari 2018 18:25]

Da's Java, geen JavaScript.
Treu, Minecraft werkt op Java dat heb je helemaal goed.
Leuk voor de kleintjes der aarde, zo is het op enorm veel platformen te spelen.
En ben je er geen dikke PC voor nodig waar niet ieder ouder over beschikt/het geld voor heeft.
En zo kunnen er zo veel mogelijk kleintjes toch plezier aan beleven, wat ik alleen maar kan toejuichen.
Zo blijft er geen een kleintje achter.
(Nou ja, zo min mogelijk dan)
:)

[Reactie gewijzigd door SSDtje op 5 januari 2018 18:14]

"JavaScript is geen scripttaal, maar gewoon een programmeertaal"

Tuurlijk, vandaar dat het de naam JavaSCRIPT heeft mee gekregen, in plaats van het alleen Java te noemen.

"JavaScript kan ook worden uitgevoerd door een run-time engine als NodeJS"

klopt, alleen is NodeJS een softwareplatform waarop men applicaties kan ontwikkelen en draaien, dus is het is dan ook niet meer dan logish dat dat kan, aangezien je hier dus ook een browser in kunt bouwen.

"Voor JavaScript (in een browser) is helemaal geen plugin nodig. Voor Java (in een browser) soms wel."

Deze twee beweringen hierboven van je kloppen ook maar deels, aangezien dat natuurlijk wel verschilt per OS wat men draait, en welke browser men gebruikt, en ik wel graag met een reactie zoveel mogelijk mensen van een degelijke uitleg wil kunnen voorzien.
"JavaScript is geen scripttaal, maar gewoon een programmeertaal"

Tuurlijk, vandaar dat het de naam JavaSCRIPT heeft mee gekregen, in plaats van het alleen Java te noemen.
Dus omdat er Script in de naam staat is het een scripttaal?
Er staat ook Java in de naam. Het is dus gewoon Java?

Het is misschien ooit ontstaan of bedoeld als scripttaal, maar heden ten dage worden er volwaardige applicaties in geschreven, dus is het gewoon een programmeertaal.
"JavaScript kan ook worden uitgevoerd door een run-time engine als NodeJS"

klopt, alleen is NodeJS een softwareplatform waarop men applicaties kan ontwikkelen en draaien, dus is het is dan ook niet meer dan logish dat dat kan, aangezien je hier dus ook een browser in kunt bouwen.
Jouw oorspronkelijke opmerking betrof "JavaScript-code kan alleen in een browser worden uitgevoerd.". Dat is dus gewoon niet zo.
"Voor JavaScript (in een browser) is helemaal geen plugin nodig. Voor Java (in een browser) soms wel."

Deze twee beweringen hierboven van je kloppen ook maar deels, aangezien dat natuurlijk wel verschilt per OS wat men draait, en welke browser men gebruikt, en ik wel graag met een reactie zoveel mogelijk mensen van een degelijke uitleg wil kunnen voorzien.
Je wilt graag zoveel mogelijk mensen van een degelijke uitleg voorzien. Da's prima. Je geeft echter een uitleg die voor verreweg de meeste mensen niet van toepassing is. Voor JavaScript heb je in de meeste browsers die door 99% van de mensen gebruikt wordt (Chrome/FireFox/IE/Edge) geen plugin nodig.
Dit is een non-discussie - het gaat hier niet over of JavaScript een taal of niet is, JS applicaties in NodeJS of WinRT zijn hier ook niet relevant, het echte probleem is dat doordat browsers 'by design' remote JavaScript code ongecheckt draaien in de JS runtime, je systeem door websites kan worden gehacked.

[Reactie gewijzigd door Dreamvoid op 5 januari 2018 17:05]

"Het is misschien ooit ontstaan of bedoeld als scripttaal, maar heden ten dage worden er volwaardige applicaties in geschreven, dus is het gewoon een programmeertaal."

Klopt, alleen dat maakt dus nog niet dat het daarvoor ook ooit bedoeld is geweest/ontwikkelt is.
Dat dat nu inmiddels wel gebeurt klopt, maar dat maakt het bovengenoemde (het daarvoor ook ooit bedoeld is geweest/ontwikkelt is) nog niet anders.

"Jouw oorspronkelijke opmerking betrof "JavaScript-code kan alleen in een browser worden uitgevoerd.". Dat is dus gewoon niet zo"

Nee klopt, maar wat verwacht je nu van mij dan, dat ik werkelijk waar elke naam van elk softwareplatform waarop men applicaties kan ontwikkelen hier ga lopen neerzetten.
;)

Edit: typo

[Reactie gewijzigd door SSDtje op 5 januari 2018 15:40]

Nee klopt, maar wat verwacht je nu van mij dan, dat ik werkelijk waar elke naam van elk softwareplatform waarop men applicaties kan ontwikkelen hier ga lopen neerzetten
Nee hoor. Ik verwacht alleen van je dat je geen dingen gaat opschrijven die gewoon niet waar zijn ;-)
Je bent niet de enige die denkt dat Java en Javascript hetzelfde is, zefls een aantal IT-ers die ik ken wisten dit niet maarja dat zijn ook geen web developers.
Ten eerste: JavaScript en Java zijn verschillende talen!
Ten tweede: als je JavaScript onwenselijk vind, dat werkt praktisch niets meer op het internet. Er gaan juist steeds meer zaken van server side naar client side, waar JavaScript een uitstekende taal voor is gebleken.

Middels projecten als Emscripten en WebAssembly is het mogelijk om native applicaties te laten draaien in een browser. Een mooi voorbeeld is de Unreal engine.
En dus, daarom, is het ook een uitstekende taal om een Spectre-aanval mee uit te voeren (daarover ging zijn vraag).
Java is iets anders dan JavaScript. Je kan inderdaad JavaScript uitschakelen maar veel websites zullen dan niet meer goed werken.
Maar het is toch vreemd dat Javascript als 'lichte/simpele' browser programmeertaal aan diepere delen van het systeem kunnen. Van wat ik tot nu toe begrijp moet je de eerst het systeem tricken dat het waardes in de cache gaat laden, maar waarom moet javascript überhaupt de cache table kunnen uitlezen? Dit lijkt mij een nogal diep verdoken functie die ik niet zomaar aanspreekbaar zou maken vanuit javascript.
Een heleboel programmeertalen moeten variabelen opslaan, en reserveren hiervoor dus ruimte in het geheugen. Door slim om te gaan met het maken van variabelen van een bepaalde grootte en het uitlezen van variabelen kan in principe misbruik gemaakt worden. Een stukje code plus uitleg hiervan is op pagina 7 te vinden van deze PDF:
https://spectreattack.com/spectre.pdf

Deze code is uiteraard niet de volledig benodigde code, dat zou een veiligheidsrisico zijn, maar geeft wel weer wat er gedaan wordt om de cache te beïnvloeden.
Zoals hoe ik het begrepen heb tracht je de caches te raden door middel van timing verschillen. M.a.w. lees je de tabel niet rechtstreeks uit.
JavaScript is al jaren geen lichte/simpele scripttaal meer.
Grappig dat Apple ook kwetsbaar lijkt voor Meltdown. Apple maakt de snelste ARM-processors die er zijn en heeft dus blijkbaar dezelfde fout gemaakt als Intel en ARM zelf (die alleen in de nieuwste Cortex A75 die fout heeft gemaakt) door niet de goede veiligheidschecks te doen bij speculative execution. Blijkbaar heeft AMD (en daarnaast bv. IBM met POWER?) écht iets goeds gedaan, met een high performance processor die wel de goede veiligheidschecks uitvoert om in ieder geval Meltdown te ontlopen. Ze zijn allemaal kwetsbaar voor Spectre, maar Meltdown is wel echt een bug met hogere impact - zowel qua security als hoe het op te lossen.

De Apple Watch zal niet kwetsbaar zijn omdat deze een in-order processor gebruikt. Dat zijn simpelere en energiezuinige processors die niet aan de speculative execution doen die nodig is voor deze twee kwetsbaarheden. Ook als je bijvoorbeeld een Android-telefoon hebt met alléén Cortex A7 of Cortex A53 cores (bv. Snapdragon 625), dan heb je ook alleen in-order processor cores en ben je veilig zonder software patches.
Je schrijft precies wat ik dacht toen ik zojuist dit nieuwsbericht las :)

Het is inderdaad een goeie vraag of de update voor iOS een hint is dat Apple's ARM cores vatbaar zouden zijn voor Meltdown. Je observatie dat ze extreem agressief zijn qua performance klopt; en het zou daar door goed kunnen dat dit per ongeluk mogelijk is, aangezien het het gevolg is van extreme performance optimalisaties.

Er is ook een duidelijke keerzijde mogelijk; Apple neemt het zekere voor het onzekere en voert dezelfde verandering door in iOS. Aangezien MacOS en iOS veel code delen op kernel niveau (beide de Darwin kernel), is het logisch dat de Meltdown fix ook naar iOS komt, omdat deze verandert hoe de Darwin kernel om gaat met het beheer van zijn page tables. Als deze fix dan in Darwin is gemaakt voor MacOS, wil je dingen zo simpel mogelijk houden en het het zelfde afhandelen voor de iOS platformen.

[Reactie gewijzigd door Squee op 5 januari 2018 12:07]

Eigenlijk draait macos en iOS op de XNU kernel. Dat weer een hybride kernel tussen de Mach 3 microkernel en BSD services

https://nl.m.wikipedia.org/wiki/XNU
En dus elk iOS apparaat welke op een oudere versie zit en geen updates meer krijgt is de sjaak.
Zouden ze inderdaad een fix voor moeten doen net zoals Windows dat deed met Wannacry :/
Waarom? Op een dag moet het gewoon gedaan zijn met updates, je kan geen 10 jaar oude code blijven onderhouden telkens er een beveiligingsrisico voorbijkomt.
10 jaar updates? Mijn ipad mini uit 2015 krijgt ook al geen updates meer na 3 jaar...
https://en.wikipedia.org/wiki/IPad_Mini

ipad mini uit 2013(en 2015) kan ios 11 nog draaien. alleen de ipad mini uit 2012 (5 jaar!) heeft als hoogste versie ios 9.
Aja? Zelfs een iPad mini 2 uit 2013 kan nog iOS 11 draaien.
Dit probleem is van die omvang dat je hier echt wel een uitzondering op wil maken. En eigenlijk is het belachelijk dat men voor beveiligingsrisico's niet langer dan tien jaar code onderhoudt.

Een auto van tien jaar oud kan ik ook nog steeds naar de garage brengen om te laten herstellen.

Waarom is dat voor software anders? Omdat? Sparkles? Regenbogen? Software is "different"? Hoezo?
Wacht maar totdat auto's een update nodig hebben om te blijven rijden. 8)7
iPhone 5S is het oudste ondersteunde device. Die ging in de verkoop in 2013. Dus op zich niet zo gek.

Maar zou Apple sieren als ze ook voor iOS 9 en 10 nog een update uitbrachten. Dan zijn ook alle iPad 2's nog meegenomen. Daar zijn er nog best veel van in aktief gebruik.
Nee oudere versies krijgen nog security updates. Die voor meltdown zou al uitgerold zijn.
Dan heb je wel een heel oud toestel. Tijd voor een nieuwe misschien.
Hij heeft het over iOS devices in de brede zin van het woord. Hoezo een heel oud toestel? Wat bedoel je? Waar slaat dat op?
Nou met oud bedoel ik dat ios (met name iphones)toestellen zo ongeveer 4 jaar updates krijgen.
De toestellen die momenteel verkocht worden hebben hetzelfde probleem. Dus je oplossing om dan maar een nieuwe te kopen lost niets op.
De discussie gaat over het krijgen van een update. Niet of de update daadwerkelijk het probleem verhelpt ;)
Apple kan dus net zo goed de oudere toestellen en hun besturingssystemen ook herstellen of updaten. Dan zou @Dutch2007 ook een update krijgen. M.a.w. is Dutch2007's kritiek terecht, en is het onterecht dat Apple er mee wegkomt dat ze geen update voorzien. Het heeft niets met de ouderdom te maken. Het is een probleem dat in zowel oude als nieuwe als huidige toestellen aanwezig is.
Het probleem kan wel op veel oudere toestellen aanwezig zijn. Het is alleen begrijpelijk dat Apple het niet wil verhelpen bij toestellen die ouder zijn dan 4 jaar. Anders snijen ze in hun eigen vingers vind ik.
Dat een verkoper van een goed soms in zijn/haar vingers snijdt is nu éénmaal het risico van handel drijven.

Het blijkt alleen bij de software industrie te zijn (waar ik deel van uitmaak) dat het altijd de consument, en nooit de producent, is die alle risico's moet dragen. Niettemin zijn de winsten in onze sector, en, ook, en, vooral bij Apple, waanzinnig, onnozel, absurd en weerzinwekkend hoog.

Dit is m.a.w. totaal niet juist. De consument hoort wel degelijk recht te hebben op updates.
Ik ben het grotendeels met je eens dat Apple absurde bedragen vraagd en krijgt. Maar oneindig updates verwachten is ook niet de juiste verwachting 4-5 jaar is in mijn ogen het max. Bij Apple hoef je over de update beleid niet te klagen vind ik. Als android fabrikanten het beter zouden doen op update gebied dan hadden we pas wat te klagen.
Autofabrikanten doen regelmatic een recall van hun voertuigen (bijvoorbeeld recent nog Audi) die vaak ook ouder zijn dan 4-5 jaar.

De kosten van herstelling van zo'n auto zijn per stuk véél hoger dan het uitrollen van een software update. De kosten van een oplossing te vinden voo het probleem (voor veel auto's) is gelijkaardig aan het herstellen van een software probleem. De winsten in de autoindustrie zijn niet hoger dan die in de software industrie. De omzetten van de autoindustrie zullen ongeveer overeen komen met die van de software industrie.

Dus waarom kan het wel voor auto's en niet voor software?
@Dutch2007 krijgt ook nog updates, hij zeurt. De iPad mini 2 uit 2013 draait zelfs nog iOS 11

Source: https://www.apple.com/lae/ios/ios-11/
Dan, is het uiteraard wel prima en zoals het hoort.
Zou zomaar kunnen dat ze dat wel doen, is in het verleden ook weleens gedaan toen de 3GS al lang niet meer werd ondersteunt. Misschien dat er voor de 32 bit apparaten ook nog wel een veiligheidspatch komt. (6.1.6 was speciaal voor 3GS)

downloads: Apple iOS 6.1.6 / 7.0.6

[Reactie gewijzigd door Mr. Freeze op 5 januari 2018 12:04]

Apple heeft patches voor Meltdown doorgevoerd bij iOS 11.2.
We zitten al op ios 11.2.1, betekent dit dat hij al lang geleden gepatched is?
Ja, dit is in December al gebeurt.
Ja. De bug is al in juni vorig jaar ontdekt en bij Intel gemeld.
Let wel op dat dit dus alleen voor Meltdown geldt. Mac- en iOS-apparaten zijn nog steeds kwetsbaar voor Spectre.
Als je 1 maand geleden 'lang geleden' vindt, dan ja.
kunnen we dan snel een jailbreak voor alles van voor iOS 11.2 verwachten? lijkt me dat zo’n lek aardig wat mogelijkheden geeft.
Er is al een jailbreak voor ios 11.1. Het is nog even wachten tot cydia aangepast is. Geen idee welke kwetsbaarheid daarvoor gebruikt is.

Is mij ook helemaal duidelijk hoe deze kwetsbaarheden tot een jailbreak moeten leiden. Het gaat toch niet om ongeoorloofde executie van code?
Hoezo meet Apple geen prestatievermindering? Als de officiele data zegt dat het tussen de 5-30% ligt? Ze gebruiken geen speciale Intel cpus ofzo. Klinkt meer alsof de marketing afdeling dit statement heeft gegeven dan de echte engineers.
Dat is niet hoe Apple het geformuleerd heeft. Ik las iets in de trant van 'bij normaal gebruik' dus onder voorbehoud.
Volgens mijn werkgever krijgen we de updates vandaag al op onze mac books, kom maar door.

Update schijnt tot 60min te kunnen duren om te installeren met tussentijdse reboots, dat klinkt dan weer wat lang.
Zal wel meevallen hoor. Je kan het ook altijd kickstarten via de terminal, dat is fijner en sneller.
Bij mij komen die updates er niet op.
Vraagje over dat Site Isolation wat in de tekst staat
chrome://flags#enable-site-per-process

Ik heb dat nu dus enabled, maar moet ik dat weer uitzetten of iets op 23 januari voordat Chrome 64 binnenkomt?

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True