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

Google: bescherming tegen Spectre-aanvallen voor Chrome-desktopversies is actief

Google heeft een beveiligingsmaatregel ingeschakeld voor het overgrote deel van de desktopgebruikers van zijn Chrome-browser. Het gaat om de feature site isolation, die moet voorkomen dat kwaadaardige websites gevoelige informatie stelen.

Google meldt dat de functie inmiddels voor 99 procent van de Chrome-gebruikers standaard is ingeschakeld, waarbij de laatste 1 procent wordt gebruikt om prestaties in de gaten te houden en zo nodig te verbeteren. De introductie van de functie vond plaats in versie 67 van Chrome, die eind mei uitkwam. In versie 66 van de browser voerde Google een beperkte test van de functie uit onder gebruikers, maakte het bekend bij de release van die versie. Het was voor zakelijke gebruikers al langer mogelijk om site isolation in te schakelen via een flag. Die mogelijkheid bestond sinds Chrome 63.

Illustratie van Google

De functie moet voorkomen dat een kwaadaardige website in staat is om gevoelige informatie te stelen van een andere website die geopend is in de browser, aldus Google. Het is een soort 'tweedelijnsverdediging', omdat same origin policy in principe al voorkomt dat websites gegevens van elkaar kunnen inzien. Site isolation gaat verder dan dat, doordat pagina's van verschillende websites in aparte processen en eigen sandboxes worden ondergebracht. Dat geldt onder meer voor tabs en iframes. Volgens Google heeft de maatregel tot gevolg dat Chrome ongeveer tien tot dertien procent meer geheugen gebruikt.

Het bedrijf schrijft dat het door het isoleren van renderer processes per site afhankelijk is van het besturingssysteem om daadwerkelijk aanvallen tussen processen te voorkomen. Voordat de functie in Chrome aanwezig was, werd een iframe van een andere site in hetzelfde proces ondergebracht als dat van de site waarop de gebruiker op dat moment aanwezig was. Dat kon ertoe leiden dat een aanvaller een succesvolle Spectre-aanval kon uitvoeren. Een dergelijke aanval maakt het uitlezen van gevoelige gegevens mogelijk, in de browser bijvoorbeeld cookies of wachtwoorden.

Google zegt dat het nu gaat onderzoeken op welke manier site isolation te integreren is in de mobiele Android-Chrome-browser. Of dat ook in de iOS-versie gebeurt, vermeldt de zoekgigant niet. Google start een experimentele implementatie voor zakelijke gebruikers in versie 68 van de Android-versie. Het bedrijf had al tegenmaatregelen in Chrome geïntroduceerd bij de publicatie van Meltdown en Spectre in januari, bijvoorbeeld door timers minder precies te maken. Deze maatregelen draait het nu weer terug, omdat die dankzij site isolation niet meer nodig zijn.

Door Sander van Voorst

Nieuwsredacteur

12-07-2018 • 10:34

63 Linkedin Google+

Reacties (63)

Wijzig sortering
Ik vind het persoonlijk vervelend dat we jarenlang beveiliging links hebben laten liggen voor de performance.

We zijn momenteel met weer een security inhaalslag bezig. De vorige was ten tijde van XP, toen men erachter kwam dat security best belangrijk was (tot aan ~2000 was het echt een non-issue). Een aantal jaar was iedereen hard bezig met security en de boel dicht timmeren. Dat is een aantal jaartjes rustig gebleven. Men bleef stil zitten, het leek alsof we 'veilig waren'.

Niets is minder waar, gezien we met deze spectre/meltdown exploits terug kunnen gaan naar de jaren 90. Dit zijn naar mijn idee echt bewuste keuzes geweest. Intel moet hier gewoon van geweten hebben. Misschien niet als bedrijf zelf, maar je kan mij niet meer vertellen dat er echt geen engineer oid de afgelopen 25 jaar zijn vraagtekens heeft gehad bij het predictive branching gebeuren, maar een oplossing kost performance, en dat kon Intel natuurlijk niet gebruiken in hun strijd jegens AMD.

Maar bedenk je eens, als in het meest complexe onderdeel van onze computers dit soort exploits gevonden worden, en 20+ jaar ongezien blijven. Bedenk je eens hoe ontzettend gaar de rest van de hardware kan zijn.

Ik denk dat we de komende jaren nog wel veel meer performance gaan inleveren om ons spul veiliger te maken.

Leuk dat jij snelheid en performance belangrijker vind dat de veiligheid van een applicatie. Je bent deel van het probleem waar we nu allemaal mee te maken krijgen. Men vond veiligheid in het verleden een non-issue, de meeste mensen vinden security momenteel nog bijzaak of in de weg zetten. We zijn wat dat betreft dus geen fuck opgeschoten in het bewustzijn van een veilige digitale omgeving, ondertussen wel allemaal zeiken op de overheid die het schijnbaar bagger slecht doet, daar werken dezelfde mensen, daar werkt hetzelfde fucking volk wat zelfs hier op Tweakers niet weet hoe ontiegelijk belangrijk die security mindset is.

Als je performance te kort komt, koop dan meer performance in. Geheugen gebruik is -vooral proffesioneel- echt een fucking non-issue. Waarom druk je er geen 64gb of 128gb in je workstation als je je zorgen maakt of je 20 tabs en Visual Studio te kort komen met het vrij standaard 8gb.

Performance nodig? Druk er Xeons in of pak de laatste Threadripper. Huur een stukje cloud in voor de performance.

Als dit soort security fixes jou systeem verandert van soepel naar sloom, zat je toch al aan de grens van de beschikbare performance zonder een beetje beenruimte over te laten.
Niets is minder waar, gezien we met deze spectre/meltdown exploits terug kunnen gaan naar de jaren 90. Dit zijn naar mijn idee echt bewuste keuzes geweest. Intel moet hier gewoon van geweten hebben. Misschien niet als bedrijf zelf, maar je kan mij niet meer vertellen dat er echt geen engineer oid de afgelopen 25 jaar zijn vraagtekens heeft gehad bij het predictive branching gebeuren, maar een oplossing kost performance, en dat kon Intel natuurlijk niet gebruiken in hun strijd jegens AMD.
Ik vraag me dit toch af, zoiets hou je lijkt mij niet 25 jaar "onder de pet" als groep van cpu fabrikanten in de tech sector, ook het feit dat op wat theoretische toespelingen na geen enkele onafhankelijke beveiligingsonderzoeker dit niet eerder aan de kaak heeft gesteld doet mij denken dat dit echt niet bekend was. Zeker ook gezien het feit dat zo'n beetje iedere cpu fabrikant er last van heeft, het is niet alleen Intel, maar ook ARM (en afgeleiden, bijvoorbeeld Apple in haar SoC's), AMD, IBM (Power) Oracle (Sparc) zijn in meer of mindere mate vatbaar voor deze security flaws.
Zijn die andere chip bakkers niet minder kwetsbaar, omdat ze het wel zagen en het proberen op te lossen, of iig te minimaliseren?

AMD had namelijk al wel gezien dat predictive branching 1 groot security risico was, en heeft security checks en features ingebakken om dit te minimaliseren/voorkomen/tegen te houden/pittig te maken.

Intel, met een R&D budget groter dan de rest bij elkaar, is de enige die zo hard geraakt wordt. Dat geeft vraagtekens die Intel dusver niet beantwoord. Ik geloof gewoonweg niet dat AMD dit wel zag, maar Intel niet.
AMD had namelijk al wel gezien dat predictive branching 1 groot security risico was, en heeft security checks en features ingebakken om dit te minimaliseren/voorkomen/tegen te houden/pittig te maken.
Dus je kunt niet met zekerheid zeggen dat Intel zich überhaupt bewust was van dit probleem, maar je brandt ze tot de grond toe af. Tegelijkertijd wist AMD duidelijk wel dat er een probleem is, maar als zij zich er vanaf maken met een gedeeltelijke oplossing, dan prijs je dat aan? Dat is echt volkomen onlogisch.
Intel, met een R&D budget groter dan de rest bij elkaar, is de enige die zo hard geraakt wordt. Dat geeft vraagtekens die Intel dusver niet beantwoord.
Hoe meer budget voor R&D, hoe geavanceerder de optimalisaties die je kunt maken. Als een extreem voorbeeld, een fabrikant die geen budget heeft om een out-of-order CPU te ontwerpen (en bij in-order blijft steken), zal nooit tegen Spectre en Meltdown aanlopen.

Heb je je ingelezen in wat deze kwetsbaarheden precies inhouden? Ik kan me levendig voorstellen dat niemand dit ziet. Zeker bij een groot team, waarbij de verantwoordelijkheden verdeeld zijn over meerdere groepen, is een probleem als dit (wat afhankelijk is van de exacte details van meerdere onderdelen van het ontwerp) makkelijk te missen.

Dus wat mij betreft is het volkomen realistisch dat ze er niet van op de hoogte waren én ik heb een soort-van onderbouwing voor de stelling dat ze het inderdaad echt niet wisten. Zonder maatregelen in hardware is deze aanval onzichtbaar uit te voeren. Oftewel, als Intel hiervan wist én hun eigen processoren gebruikt in al hun eigen computers (geen idee of dat zo is, maar "Intel gebruikt zelf alleen maar AMD cpus" lijkt het soort krantenkop die snel uitlekt), dan nemen ze bewust het risico dat al hun eigen data en geheimen gestolen worden, zonder dat ze ooit kunnen achterhalen óf het gebeurd is, en zo ja, wie het gedaan heeft. Is dat een realistische aanname voor het moment waarop ze erachter komen, terwijl ze als een gek proberen het zo snel mogelijk te fixen? Ja, bij gebrek aan een alternatief (en, wat zouden ze anders kunnen doen?) zullen ze wel moeten. Maar is dat een realistische aanname vanaf het moment dat ze erachter komen... en vervolgens talloze jaren besluiten dat het wel prima is? Nee sorry, dat zie ik echt niet gebeuren.
Ik geloof gewoonweg niet dat AMD dit wel zag, maar Intel niet.
En ik geloof gewoonweg niet dat de aarde rond is. En nee, daar ga ik geen enkele zinnige onderbouwing voor geven, daarvoor weet ik het te zeker...!?
AMD is niet kwetsbaar voor Meltdown, Intel en ARM wel in bepaalde ranges cpu's, Spectre zijn ze allemaal vatbaar voor zo voor zover mij bekend. AMD Ryzen vanwege de checks die je al noemt zo lijkt het wel lastiger dan bijvoorbeeld Intel in het geval van Spectre. Maar goed Ryzen is ook een relatief nieuw ontwerp qua architectuur. Het ontwerp waar bijv. Intel op voortborduurt is alweer zo'n 10-11 jaar oud (uiit mijn hoofd gelanceerd in 2009 in de eerste iteratie en daarvoor dan minimaal 1-2 jaar in ontwikkeling), en wat ik begrijp kan zo'n ontwerp niet zomaar aangepast worden, maar is daar echt een volledig nieuw design voor nodig.
Ryzen zou juist geen doorontwikkeling zijn op Bulldozer, zie:
Zen is a clean sheet design that differs from the long-standing Bulldozer architecture. Zen-based processors use a 14 nm FinFET process, are reportedly more energy efficient, and can execute significantly more instructions per cycle. SMT has been introduced, allowing each core to run two threads. The cache system has also been redesigned, making the L1 cache write-back. Zen processors use three different sockets: desktop and mobile Ryzen chips use the AM4 socket, bringing DDR4 support;
Heb je meer info over die bios aanpassing? Ik meende namelijk dat dit geen bios aanpassing betrof maar het aanzetten van BPF JIT binnen de Linux kernel (niet van toepassing op Windows machines).

Zie de volgende quote:
A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time.
Hoe dan ook, dat zou alleen voor variant Spectre V1 van toepassing zijn en die variant wordt al volledig gedicht voor zowel Intel als AMD in OS patches.

AMD zelf geeft aan dat in ieder geval Bulldozer en up vatbaar zijn voor Spectre V2, met de kanttekening dat ze denk dat het zeer lastig te exploiten zal zijn, iets dat ik best geloof. Echter iets dat nu lastig is, kan over een maand, een jaar een stuk makkelijker zijn. Vandaar dat AMD ook hier gewoon, net zoals Intel, werkt aan Microcode om deze vunerability te verhelpen, naast de benodigde OS patches.

Wat ARM betreft ben ik ook niet volledig op de hoogte, ik begreep echter wel juist het tegenover gestelde, dat ARM meer de Intel kant op zit (want bijv. ook vatbaar voor Meltdown).
Masterkey heeft echter niets met Spectre / Meltdown of varianten te maken, dat was onderdeel van die enigzins wazige CTS labs onthulling.
Ryzen lijkt in niets op Bulldozer. Werkelijk alles is anders. Frontend, ALU's, caches, multithreading. En er zitten geen checks in om Meltdown te voorkomen, het verschil met Intel is dat bij de laatste de bounds check later in de pipeline zit, wat agressievere optimalisatie mogelijk maakt.

Iemand nog interesse in een FX-8350E? Met gratis uitgebrand moederbord erbij! Blijkbaar zijn 4 power phases te weinig voor een volledig belaste Bulldozer. Bord heeft het toch nog 3 maanden volgehouden, knap. Leermomentje ;-)
Side channels (want tot deze categorie behoren de Meltdown en Spectre attacks) zijn eigenlijk pas echt onderkend sinds het AES selectie proces, zo'n 20 jaar geleden. Het vereist een compleet nieuw paradigma qua denken om ze te voorkomen en toch te kunnen optimaliseren. Er is een hele goede reden dat AES tegenwoordig in hardware uitgevoerd is.
Het gaat om authenticity, confidentiality, en integrity.

Parallel daar aan: veilig, toegankelijk/gebruikersvriendelijk, en performance is een combinatie die moeilijk samen gaat. Vaak is het niet zo ingewikkeld 2 v/d 3 te combineren, maar 3 v/d 3 wel.
We zijn momenteel met weer een security inhaalslag bezig. De vorige was ten tijde van XP, toen men erachter kwam dat security best belangrijk was (tot aan ~2000 was het echt een non-issue). Een aantal jaar was iedereen hard bezig met security en de boel dicht timmeren. Dat is een aantal jaartjes rustig gebleven. Men bleef stil zitten, het leek alsof we 'veilig waren'.
Dit is projecting nonsense, dat nergens op slaat (kijk maar naar ASLR dat na XP gemeengoed is geworden). Windows is slechts 1 v/d OSen, en beveiliging is een constant kat- en muis spel. Voor XP had je al UNIX machines waar je op in kon bellen met guest accounts, of services die standaard allemaal moesten draaien "want dat was handig" (ja, ook Linux deed daar aan mee). Windows 9x was single user. Maar je kunt niet zeggen dat de opvolgers van XP (Vista, 7, en 10) geen verbeteringen hadden tov beveiliging, of dat Windows 2000 geen verbetering had tov NT 4.0.

Wel is het zo dat het internet opkwam en ineens machines een veel groter potentieel publiek hadden met alle gevolgen van dien. Ook is het zo dat niet iedere vooruitgang niet gepaard gaat met neveneffecten. En er liggen nog steeds kansen voor verbetering want bijvoorbeeld ECC geheugen is nog steeds verre van standaard.
Ik ben dan wel benieuwd hoe je met systeem om gaat als je dat vandaag de dag nog met regelmaat opnieuw zit te installeren. Ik kloot ook veel met mijn systeem aan zowel de software als hardware kant. Mijn originele Windows 10 install staat er nog op, welke geupgrade werd van Windows 8, welke geuprade werd van een ~2 jaar oude Win7 installatie. Alhoewel dit niet echte upgrades waren, mijn software/games en meuk staat niet op de OS disk en de meeste software gaat niet meer stuk bij ontbrekende registry entries e.d. Dus het is technisch een verse install eigenlijk.


Als je een code klopper bent, is security echt wel belangrijk. Zelfs als je niet getarget wordt, kan je op leuke darknest lijstjes terecht komen, en er is vanzelf iemand die jou werk interessant vind. Want ik neem aan dat je de software niet voor jezelf schrijft maar voor derden.

Lekker als men dus toegang krijgt tot jou source code omdat je de moeite niet neemt veiligheid serieus te nemen. Gister nog nieuws over die Hola addon en hoe simpel het eigenlijk is om je gebruikers/klanten de lul te laten worden van je eigen brakke security policies.
Hier ben ik het dus ook mee eens. Gelukkig heb ik recentelijk een CPU upgrade gedaan, maar voorheen had ik echt elke cycle nodig tijdens het gamen, omdat ik anders FPS drops kreeg.
maar voorheen had ik echt elke cycle nodig tijdens het gamen
Dan sluit je toch gewoon je browser?
Ja, dat helpt idd, maar ik gebruik mijn browser regelmatig -> alt-tab en dan even een search voor een quest of guide oid.
Dan zie 't maar zo: je verliest (in je oude situatie of niet) dan misschien een paar FPS maar dat is nog niks vergeleken bij de FPS die je verliest als je PC onder de virussen, coinminers en cryptolockers zit (of erger; je rekening geplunderd, je PC stuk en dus geen centen meer voor een nieuwe = 0 FPS) ;)
Daarvoor heb ik een extra laptop en iPad. Ik kwam er al snel achter dat dat een stuk beter werkte ... voor mij. Kon ik het er zonder extra performance in te leveren mooi naast houden.
Ik snap dat het voor sommige mensen en beroepen interessant en belangrijk is
Totdat je rekening wordt leeggeplunderd toen je ging telebankieren. Maar gelukkig draaide je Visual Studio een fractie sneller! *O*
Ik wil je wel eens horen piepen anders als je computer onder de virussen zit, je bankrekening geplunderd is, je mail op straat ligt of je privé-foto's op het web te vinden zijn. Dat is allemaal (en véél meer dan dat) mogelijk met zulke vulnerabilities. Ja, daar offer ik graag 10-13% van m'n performance voor op ja. Nog wel meer ook als 't moet. Je kunt wel chagrijnen maar als 't je overkomt piep je wel anders :>
alleen er zijn zat scenario's waarin het niet echt een issue is
En hoe moeten de Chrome devs weten dat 't voor Pietje (vandaag, toevallig) geen issue is (maar morgen waarschijnlijk alsnog?). Ik bedoel: hoe zie jij 't voor je dat ze dan zo'n vulnerability aanpakken? Met een opt-in vinkje? Liefst nog met er de tekst "Ja, ik wil graag veiliger browsen ten koste van 10-13% van m'n performance" er bij zeker... enig idee hoeveel mensen dat vinkje dan gaan aanzetten? Sommige keuzes moet je gewoon niet aan de (eind)gebruiker over laten; soms moet je gewoon wat vervelends voor lief nemen ten koste van het groter goed. Simpel.
Ik doelde meer op het sentiment dat er patches zijn die negatief de performance beïnvloeden en dat sommige mensen dit irritant vinden.

Ben benieuwd of dit dan ook voor Meteor applicaties gaat gelden.
Oh dear, dat is niet echt een populaire mening hier op tweakers. :)
Net als met het patchbeleid op Windows....

Maar ik snap het wel.
Als je zo min mogelijk geheugen wilt gebruiken dan kun je beter geen chrome gebruiken. Door de sandboxing heeft deze browser altijd al een redelijk hoog geheugengebruik gehad.

Er is keuze in de browserwereld en als je licht wil browsen kun je volgens mij beter firefox gebruiken, maar dat kun je misschien zelf beter even opzoeken. Zelf gebruik ik wel gewoon chrome en neem ik het geheugengebruik voor lief. Als je voldoende hebt merk je er niks van.
Bij mij is bijna de helft van mijn 32GB RAM standaard in gebruik door Chrome.. :|
Ik dacht dat dit op OS niveau al kon worden afgevangen?
Site isolation gaat verder dan dat, doordat pagina's van verschillende websites in aparte processen en eigen sanboxes worden ondergebracht. Dat geldt onder meer voor tabs en iframes. Volgens Google heeft de maatregel tot gevolg dat Chrome ongeveer tien tot dertien procent meer geheugen gebruikt.
Dat is best flink, hopelijk gaat dit dan ook niet ten laste van de snelheid?
Ik dacht dat dit op OS niveau al kon worden afgevangen?
[...]
Dat is best flink, hopelijk gaat dit dan ook niet ten laste van de snelheid?
Het hele idee van de spectre-aanvallen is juist dat het ene proces de data van een ander proces (dus ook het OS zelf) kan lezen, terwijl het OS er weinig aan kan doen zonder fors in te leveren op het gebied van performance (pakweg 10% tot 35%) en zelfs dan is men nog net helemaal veilig.

Op OS-niveau kan men alleen een scheiding aanbrengen tussen verschillende processen. Nou gebruikt Chrome inderdaad 1 proces per tabblad, maar dit zijn child-processes van het hoofdproces van Chrome, waardoor er dus veel (lees, meer dan genoeg voor een aanval) informatie van het Chrome-hoofdproces wordt doogegeven aan het kind.

De hardware kan de pijn enigszins verzachten door voor ieder proces een eigen ruimte (context) te maken waarin een bepaald groepje processen kan draaien. Helaas is het zo dat de betreffende processor maar net de PCID-feature moet hebben en dat zelfs dan de hardware slechts 4096 contexten beschikbaar kan stellen.

Heeft de CPU de PCID-feature en draait men niet al teveel losse processen (lees iedere open tab is een proces met Chrome), dan kijkt men aan tegen een 5% verlies van performance. Heeft men de PCID-feature niet of gaat men meer dan 4096 processen starten, dan kijkt u aan tegen de eerdergenoemde 10% tot 35% verlies van snelheid.

Google neemt dus gewoon het zekere voor het onzekere en voegt maar gewoon een extra laag beveiliging toe. Google wil geen rechtszaken van gebruikers omdat zij nalatig zijn geweest bij het bouwen van, misschien wel het belangrijkste stuk software dat de hele wereld nu gebruikt (de Chrome browser). Pech dus voor de performance.... Dit hele debacle is tevens de schuld van Intel en niet van Google.

[Reactie gewijzigd door vliegendekat op 12 juli 2018 11:32]

Ik dacht dat dit op OS niveau al kon worden afgevangen?
Meltdown: Ja, door KPTI toe te passen. Voor Spectre v2 tussen processen kan het OS wel wat doen, maar voor v1 en v2 (en ook v1.2, v1.2 en v4...) ben je binnen het zelfde proces wel nog steeds kwetsbaar. Dit is dus in situaties waar je binnen een proces meerdere dingen hebt lopen die van buitenaf geladen worden, die niet van elkaar mogen lezen (zoals je Javascript VM in je browser). Dan kan je dat of in software oplossen, of bepaalde hardware features uitschakelen met alle nadelige performance effecten van dien (en die kunnen alleen v2 en v4 oplossen ten koste van flink wat performance). Blijkbaar heeft Google nu in Chrome voldoende software gebaseerde oplossingen/workarounds gestopt zodat het weer veilig zou moeten zijn.


Om te kunnen reageren moet je ingelogd zijn


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. © 1998 - 2018 Hosting door True