Meltdown/spook

Surma

Overzicht

Op 3 januari onthulde Project Zero kwetsbaarheden in moderne CPU's die een proces kan gebruiken om (in het slechtste geval) willekeurig geheugen te lezen - inclusief geheugen dat niet tot dat proces behoort. Deze kwetsbaarheden heten Spectre en Meltdown . Wat doet Chrome om het internet veilig te houden, en wat moeten webontwikkelaars doen voor hun eigen sites?

TL; DR

Als gebruiker die op internet surft , moet u ervoor zorgen dat u uw besturingssysteem en browser up-to-date houdt. Bovendien kunnen Chrome-gebruikers overwegen Site-isolatie in te schakelen.

Als u een webontwikkelaar bent, adviseert het Chrome-team het volgende :

• Voorkom waar mogelijk dat cookies het geheugen van het rendererproces binnendringen door de cookiekenmerken SameSite en HTTPOnly te gebruiken en door het lezen van document.cookie te vermijden.
• Zorg ervoor dat uw MIME-typen correct zijn en specificeer een X-Content-Type-Options: nosniff header voor URL's met gebruikersspecifieke of gevoelige inhoud, om het meeste uit Cross-Origin Leesblokkering te halen voor gebruikers voor wie Site-isolatie is ingeschakeld.
• Schakel Site-isolatie in en laat het Chrome-team weten of dit problemen veroorzaakt voor uw site.

Als je je afvraagt ​​waarom deze stappen helpen, lees dan verder!

Het risico

Er is een grote verscheidenheid aan verklaringen voor deze kwetsbaarheden, dus ik ga er niet nog een toevoegen. Als u geïnteresseerd bent in hoe deze kwetsbaarheden kunnen worden uitgebuit, raad ik u aan de blogpost van mijn collega's van het Google Cloud-team te bekijken.

Zowel Meltdown als Spectre zorgen er mogelijk voor dat een proces geheugen kan lezen dat het niet zou moeten kunnen. Soms kunnen meerdere documenten van verschillende sites een proces in Chrome delen. Dit kan gebeuren wanneer de een de ander heeft geopend met window.open , of <a href="..." target="_blank"> , of iframes. Als een website gebruikersspecifieke gegevens bevat, bestaat de kans dat een andere site deze nieuwe kwetsbaarheden kan gebruiken om die gebruikersgegevens uit te lezen.

Mitigaties

Het technische team van Chrome en V8 levert meerdere inspanningen om deze dreiging te beperken.

Locatie-isolatie

De impact van het succesvol exploiteren van Spectre kan aanzienlijk worden verminderd door te voorkomen dat gevoelige gegevens ooit een proces delen met door de aanvaller bestuurde code. Het Chrome-team heeft gewerkt aan een functie om dit te bereiken, genaamd ' Site-isolatie ':

Opmerking: “Websites hebben doorgaans geen toegang tot elkaars gegevens in de browser[...]. Af en toe worden er beveiligingsfouten in deze code aangetroffen en kunnen kwaadwillende websites proberen deze regels te omzeilen om andere websites aan te vallen. [...] Site-isolatie biedt een tweede verdedigingslinie om ervoor te zorgen dat dergelijke aanvallen minder kans van slagen hebben. Het zorgt ervoor dat pagina's van verschillende websites altijd in verschillende processen worden geplaatst, die elk in een sandbox draaien die beperkt wat het proces mag doen. ”

Site-isolatie is nog niet standaard ingeschakeld omdat er een aantal bekende problemen zijn en het Chrome-team graag zoveel mogelijk veldtesten wil doen. Als u een webontwikkelaar bent, moet u Site-isolatie inschakelen en controleren of uw site functioneel blijft. Als u zich nu wilt aanmelden, schakelt u chrome://flags#enable-site-per-process . Als u een site tegenkomt die niet werkt, kunt u ons helpen door een bug in te dienen en te vermelden dat u Site-isolatie heeft ingeschakeld.

Cross-site documentblokkering

Opmerking: Na de publicatie van dit document is de naam Cross-Site Document Blocking gewijzigd in Cross-Origin Read Blocking . Deze twee termen verwijzen naar hetzelfde concept.

Zelfs als alle cross-site pagina's in afzonderlijke processen worden geplaatst, kunnen pagina's nog steeds op legitieme wijze bepaalde cross-site subbronnen opvragen, zoals afbeeldingen en JavaScript. Om te helpen voorkomen dat gevoelige informatie deze informatie lekt, bevat Site Isolation een functie voor het blokkeren van documenten tussen sites die beperkt welke netwerkreacties worden geleverd aan het rendererproces.

Een website kan twee soorten gegevens van een server opvragen: ‘documenten’ en ‘bronnen’. Hier zijn documenten HTML-, XML-, JSON- en tekstbestanden. Een website kan documenten ontvangen van het eigen domein of van andere domeinen met tolerante CORS-headers. Hulpbronnen omvatten zaken als afbeeldingen, JavaScript, CSS en lettertypen. Bronnen kunnen vanaf elke site worden opgenomen.

Het cross-site documentblokkeringsbeleid voorkomt dat een proces “documenten” van andere oorsprong ontvangt als:

1. Ze hebben een HTML-, XML-, JSON- of tekst/plain MIME-type, en
2. Ze hebben een X-Content-Type-Options: nosniff HTTP-antwoordheader, of een snelle inhoudsanalyse (“ sniffing ”) bevestigt dat het type correct is
3. CORS staat niet expliciet toegang tot het document toe

Documenten die door dit beleid worden geblokkeerd, worden als leeg aan het proces gepresenteerd, hoewel het verzoek nog steeds op de achtergrond plaatsvindt.

Bijvoorbeeld: Stel je voor dat een aanvaller een <img> -tag maakt die een JSON-bestand met gevoelige gegevens bevat, zoals <img src="https://yourbank.com/balance.json"> . Zonder site-isolatie zou de inhoud van het JSON-bestand in het geheugen van het rendererproces terechtkomen, waarna de renderer merkt dat het geen geldig afbeeldingsformaat is en geen afbeelding rendert. Met Spectre is er nu echter een manier om dat deel van het geheugen mogelijk te lezen. Cross-site documentblokkering voorkomt dat de inhoud van dit bestand ooit in het geheugen terechtkomt van het proces waarin de renderer wordt uitgevoerd, omdat het MIME-type wordt geblokkeerd door cross-site documentblokkering.

Volgens gebruikersstatistieken zijn er veel JavaScript- en CSS-bestanden die worden geleverd met text/html of text/plain MIME-typen. Om te voorkomen dat bronnen worden geblokkeerd die per ongeluk als documenten zijn gemarkeerd, probeert Chrome het antwoord op te sporen om er zeker van te zijn dat het MIME-type correct is. Dit snuiven is onvolmaakt, dus als u er zeker van bent dat u de juiste Content-Type headers op uw website instelt, raadt het Chrome-team aan om de X-Content-Type-Options: nosniff header toe te voegen aan al uw reacties.

Als u het blokkeren van documenten tussen sites wilt proberen, meld u dan aan voor Site-isolatie, zoals hierboven beschreven.

SameSite cookies

Laten we teruggaan naar het bovenstaande voorbeeld: <img src="https://yourbank.com/balance.json"> . Dit werkt alleen als yourbank.com een ​​cookie heeft opgeslagen waarmee de gebruiker automatisch wordt aangemeld. Cookies worden doorgaans voor alle verzoeken verzonden naar de website die de cookie instelt, zelfs als het verzoek wordt gedaan door een derde partij met behulp van een <img> -tag. SameSite-cookies zijn een nieuw kenmerk dat specificeert dat een cookie alleen mag worden toegevoegd aan een verzoek dat afkomstig is van dezelfde site, vandaar de naam. Helaas ondersteunen op het moment van schrijven alleen Chrome en Firefox 58+ dit kenmerk .

HTTPOnly en document.cookie

Als de cookies van uw site alleen op de server worden gebruikt en niet door client-JavaScript, zijn er manieren waarop u kunt voorkomen dat de gegevens van de cookie in het weergaveproces terechtkomen. U kunt het cookie-kenmerk HTTPOnly instellen, waarmee expliciet wordt voorkomen dat de cookie wordt geopend via client-side script in ondersteunde browsers, zoals Chrome. Als het instellen van HTTPOnly niet mogelijk is, kunt u de blootstelling van het laden van cookiegegevens aan het weergegeven proces helpen beperken door document.cookie niet te lezen, tenzij dit absoluut noodzakelijk is.

Externe links openen met rel="noopener"

Wanneer u naar een andere pagina linkt met behulp van target="_blank" , heeft de geopende pagina toegang tot uw window , kan uw pagina naar een andere URL navigeren en zonder site-isolatie bevindt deze zich in hetzelfde proces als uw pagina. Om uw pagina beter te beschermen, moeten links naar externe pagina's die in een nieuw venster worden geopend altijd rel="noopener" specificeren .

Timers met hoge resolutie

Om Meltdown of Spectre te kunnen misbruiken, moet een aanvaller meten hoe lang het duurt om een ​​bepaalde waarde uit het geheugen te lezen. Hiervoor is een betrouwbare en nauwkeurige timer nodig.

Eén API die het webplatform biedt is performance.now() die tot op 5 microseconden nauwkeurig is. Als oplossing hebben alle grote browsers de resolutie van performance.now() verlaagd om het moeilijker te maken de aanvallen uit te voeren.

Een andere manier om een ​​timer met hoge resolutie te krijgen, is door een SharedArrayBuffer te gebruiken. De buffer wordt door een toegewijde medewerker gebruikt om een ​​teller te verhogen. De hoofdthread leest deze teller en gebruikt die als timer. Voorlopig hebben browsers besloten SharedArrayBuffer uit te schakelen totdat er andere oplossingen zijn getroffen.

V8

Om Spectre te kunnen exploiteren, is een specifiek vervaardigde reeks CPU-instructies nodig. Het V8-team heeft oplossingen geïmplementeerd voor bekende aanvalsproofs of concept, en werkt aan veranderingen in TurboFan, hun optimaliserende compiler, die de gegenereerde code veilig maken, zelfs wanneer deze aanvallen worden geactiveerd. Deze wijzigingen in het genereren van code kunnen echter een prestatieverlies met zich meebrengen.

Het internet veilig houden

Er is veel onzekerheid geweest rond de ontdekking van Spectre en Meltdown en hun implicaties. Ik hoop dat dit artikel enig licht werpt op wat de Chrome- en V8-teams doen om het webplatform veilig te houden, en hoe webontwikkelaars kunnen helpen door bestaande beveiligingsfuncties te gebruiken. Als je vragen hebt, neem dan gerust contact met mij op via Twitter .