Chrome patcht 24 beveiligingsgaten, maakt "Sanitizer" veiligheidssysteem mogelijk

Google's nieuwste Chrome-browser, versie 105, is uit, hoewel het volledige versienummer irritant verschilt, afhankelijk van of je Windows, Mac of Linux gebruikt.

Op Unix-achtige systemen (Mac en Linux) wil je: 105.0.5195.52, maar in Windows zoekt u 105.0.5195.54.

Volgens Google bevat deze nieuwe versie 24 beveiligingsreparaties, hoewel geen van deze wordt gerapporteerd als "in-the-wild", wat betekent dat er deze keer geen zero-days zijn gepatcht.

Toch is er één kwetsbaarheid genaamd kritisch, en nog eens acht beoordeeld Hoge.

Van de fouten die zijn verholpen, is iets meer dan de helft te wijten aan wanbeheer van het geheugen, met negen vermeld als gebruik-na-gratis bugs, en vier als heapbuffer loopt over.

Typen geheugenbugs uitgelegd

A gebruik-na-gratis is precies wat het zegt: je geeft geheugen terug om het vrij te maken voor een ander deel van het programma, maar blijft het toch gebruiken, waardoor de juiste werking van je app mogelijk wordt verstoord.

Stel je bijvoorbeeld voor dat het deel van het programma dat denkt dat het nu alleen toegang heeft tot het aanstootgevende geheugenblok, wat niet-vertrouwde invoer ontvangt en zorgvuldig controleert of de nieuwe gegevens veilig te gebruiken zijn...

... maar dan, op het moment voordat het die gevalideerde invoer begint te gebruiken, interfereert uw buggy "use-after-free"-code en injecteert oude, onveilige gegevens in hetzelfde deel van het geheugen.

Plots gedraagt ​​​​bug-vrije code elders in het programma zich alsof het zelf een bug is, dankzij de fout in je code die net ongeldig maakte wat in het geheugen stond.

Aanvallers die een manier kunnen bedenken om de timing van de onverwachte interventie van uw code te manipuleren, kunnen niet alleen het programma naar believen laten crashen, maar ook de controle ervan ontnemen, waardoor wat bekend staat als uitvoering van externe code.

En een heap buffer overloop verwijst naar een bug waarbij u meer gegevens naar het geheugen schrijft dan past in de ruimte die oorspronkelijk aan u was toegewezen. (Hoop is de jargonterm voor de verzameling geheugenblokken die momenteel door het systeem worden beheerd.)

Als een ander deel van het programma toevallig een geheugenblok in de buurt van of naast het jouwe in de hoop heeft, dan zullen de overbodige gegevens die je zojuist hebt opgeschreven niet onschadelijk overlopen in ongebruikte ruimte.

In plaats daarvan corrumpeert het gegevens die ergens anders actief worden gebruikt, met vergelijkbare gevolgen als wat we zojuist hebben beschreven voor een use-after-free-bug.

Het “Sanitizer” systeem

Gelukkig heeft Google, naast het oplossen van fouten die er helemaal niet horen te zijn, de komst aangekondigd van een nieuwe functie die voegt bescherming toe tegen een klasse van browserfouten die bekend staat als cross-site scripting (XSS).

XSS-bugs worden veroorzaakt doordat de browser niet-vertrouwde gegevens invoegt, bijvoorbeeld van een webformulier dat door een externe gebruiker is ingediend, rechtstreeks in de huidige webpagina, zonder eerst te controleren op (en te verwijderen) risicovolle inhoud.

Stel je bijvoorbeeld voor dat je een webpagina hebt die aanbiedt om me te laten zien hoe een tekenreeks van mijn keuze eruitziet in je funky nieuwe lettertype.

Als ik de voorbeeldtekst typ Cwm fjord bank glyphs vext quiz (een gekunstelde maar vaag betekenisvolle mashup van Engels en Welsh die alle 26 letters van het alfabet in slechts 26 letters bevat, voor het geval je je dat afvroeg), dan is het veilig voor jou om die exacte tekst in de webpagina die je maakt te zetten.

In JavaScript zou je bijvoorbeeld de hoofdtekst van de webpagina als volgt kunnen herschrijven, door de tekst in te voegen die ik heb geleverd zonder enige wijziging:

document.body.innerHTML = " Cwm fjord bank glyphs vext quiz"

Maar als ik vals speelde en je vroeg om de tekstreeks te "weergeven"? Cwm fjord<script>alert(42)</script> in plaats daarvan zou het roekeloos van je zijn om dit te doen...

document.body.innerHTML = " Cwm fjord alert(42) "

...omdat je me zou toestaan ​​om niet-vertrouwde JavaScript-code van te injecteren my direct kiezen in jouw webpagina, waar mijn code uw cookies kan lezen en toegang kan krijgen tot gegevens die anders niet toegankelijk zouden zijn.

Dus, om te maken wat bekend staat als uw ingangen opschonen gemakkelijker, Chrome heeft nu officieel ondersteuning ingeschakeld voor een nieuwe browserfunctie genaamd setHTML().

Dit kan worden gebruikt om nieuwe HTML-inhoud te pushen via een functie genaamd de Sanitizer eerst, zodat als u in plaats daarvan deze code gebruikt...

document.body.setHTML(" Cwm fjord alert(42) ")

... dan scant Chrome eerst de voorgestelde nieuwe HTML-tekenreeks op beveiligingsproblemen en verwijdert automatisch alle tekst die een risico zou kunnen vormen.

Je kunt dit in actie zien via de Ontwikkelaarstools door het bovenstaande uit te voeren setHTML() code bij de troosten prompt, en vervolgens het ophalen van de daadwerkelijke HTML die in de is geïnjecteerd document.body variabel, zoals we hier deden:

Hoewel we expliciet een <script> tag in de invoer die we hebben doorgegeven aan de setHTML() functie, is de scriptcode automatisch verwijderd uit de gemaakte uitvoer.

Als u echt potentieel gevaarlijke tekst aan een HTML-element moet toevoegen, kunt u een tweede argument toevoegen aan de setHTML() functie die verschillende soorten risicovolle inhoud specificeert om te blokkeren of toe te staan.

Als dit tweede argument zoals hierboven wordt weggelaten, werkt de Sanitizer standaard op het maximale beveiligingsniveau en verwijdert automatisch alle gevaarlijke inhoud waarvan hij op de hoogte is.

Wat te doen?

• Als u een Chrome-gebruiker bent. Controleer of je up-to-date bent door te klikken op Drie puntjes > Help > Over Google Chrome, of door te bladeren naar de speciale URL chrome://settings/help.
• Als je een webprogrammeur bent. Lees meer over het nieuwe Sanitizer en setHTML() functionaliteit door te lezen advies van Google en MDN-webdocumenten.

---

Trouwens, als je Firefox gebruikt, Sanitizer is beschikbaar, maar is nog niet standaard ingeschakeld. Je kunt het inschakelen om er meer over te weten te komen door naar about:config en het omschakelen van de dom.security.sanitizer.enabled optie om true.

---