image

Google voorziet Chrome van hardware-enforced stack protection

woensdag 5 mei 2021, 17:15 door Redactie, 11 reacties

Google heeft de nieuwste Windowsversie van Chrome voorzien van een beveiligingsmaatregel genaamd hardware-enforced stack protection die het lastiger moet maken voor aanvallers om kwetsbaarheden te misbruiken. Bij deze technologie gebruikt de processor een shadow stack, een nieuwe, beschermde stack met return adressen.

De feature is beschikbaar voor Chrome-gebruikers op Windows 10 versie 20H1 (December Update) of nieuwer, die gebruikmaken van een processor met Control-flow Enforcement Technology (CET) zoals elfde generatie Intel- of AMD Zen 3-processoren, zo laat Google in een blogpost weten.

Een veelvoorkomende kwetsbaarheid is de zogenaamde use-after-free (UAF), waarbij een aanvaller het aangevallen programma een door hem gekozen pointer laat aanroepen. Hier heeft de aanvaller controle over een object dat de adresruimte gebruikt die eerder door een ander object in gebruik was en door het programma gebruikt blijft worden. Vervolgens kan de aanvaller zijn code laten aanroepen die hij wil uitvoeren.

In het verleden kon een aanvaller zijn shellcode naar een bekende geheugenlocatie schrijven en dan de instructiepointer naar deze shellcode laten wijzen. Om te voorkomen dat stacks of heaps uitvoerbaar waren werd Data Execution Prevention toegevoegd. In een reactie hierop kwamen aanvallers met Return Oriented Programming (ROP). Hierbij maken aanvallers misbruik van de eigen code van een proces, aangezien die uitvoerbaar moet zijn.

Via controle over de stack en de instructiepointer kan een aanvaller de 'ret' instructie gebruiken om naar verschillende, handige stukken code te springen. Tijdens een exploit wordt de instructiepointer aangepast zodat niet de normale bestemming wordt aangeroepen, maar een klein gedeelte van de code genaamd een ROP-gadget. Door deze gadgets aan elkaar te koppelen kan een aanvaller uiteindelijk een gewenste functie aanroepen.

Stack protection moet dergelijke aanvallen lastiger maken. Naast de bestaande stack beschikt de processor over een shadow stack. Deze stack is niet direct door een programma te manipuleren en bevat alleen return adressen. De ret-instructie maakt nog steeds gebruik van de return adressen van de normale stack, maar controleert nu dat die gelijk is aan het adres dat in de shadow stack is opgeslagen. Wanneer dit het geval is blijft het programma gewoon werken. Komen de adressen niet overeen, dan doet zich een exception voor die door het besturingssysteem wordt onderschept. Het besturingssysteem kan de shadow-regio aanpassen zodat het programma blijft werken, maar in de meeste gevallen wordt het programma meteen beëindigd, aldus Google.

Naast Chrome kunnen ook andere programma's van hardware-enforced stack protection gebruikmaken. Via de Windows Task Manager kan worden gekeken of de maatregel staat ingeschakeld. Dit is zichtbaar via de Details-tab van de Task Manager en dan de procesweergave. "Het inschakelen van hardware-enforced stack protection past met bestaande en toekomstige maatregelen om misbruik lastiger en kostbaarder voor een aanvaller te maken, en zo de mensen te beschermen die Chrome dagelijks gebruiken", zegt Alex Gough van het Chrome Platform Security Team.

Reacties (11)
05-05-2021, 17:41 door Anoniem
Het is toch wat wat je allemaal moet doen om het onder windows veiliger te krijgen. Vechten tegen de bierkaai. Waarom zou Google hier zo veel moeite insteken? Ze gebruiken zelf helemaal geen windows desktops
05-05-2021, 19:01 door Anoniem
Begrijp ik hieruit goed dat de stack in Windows niet beschermd is met canaries?
05-05-2021, 20:43 door Anoniem
Door Anoniem: Begrijp ik hieruit goed dat de stack in Windows niet beschermd is met canaries?

Stomme vraag.

Sorry, foutje van mij.
05-05-2021, 20:46 door Anoniem
Door Anoniem: Het is toch wat wat je allemaal moet doen om het onder windows veiliger te krijgen. Vechten tegen de bierkaai. Waarom zou Google hier zo veel moeite insteken? Ze gebruiken zelf helemaal geen windows desktops

Het heeft vrij weinig met Windows te maken sinds het een hardware functie is.
Goede kans dat het ook op Linux gebruikt gaat worden en CET kan natuurlijk ook in arm architectuur geimplementeerd worden.

Het OS moet dus wel ondersteunig bieden voor deze hardware functie dus zal ook naar linux komen.
06-05-2021, 02:29 door Anoniem
Door Anoniem: Het is toch wat wat je allemaal moet doen om het onder windows veiliger te krijgen. Vechten tegen de bierkaai. Waarom zou Google hier zo veel moeite insteken? Ze gebruiken zelf helemaal geen windows desktops

Het is inderdaad een drama.

Parafrasering van een security-specialist op Black-Hat (Las Vegas): "Ik durf hier niet mijn laptop te booten".
06-05-2021, 07:47 door Anoniem
Door Anoniem: [...] Waarom zou Google hier zo veel moeite insteken? [...]
Google doet dit omdat ze, in tegenstelling tot Mozilla, er niet voor gekozen hebben om de webbrowser te (her)schrijven in een memory-safe programmeertaal zoals Rust.
06-05-2021, 10:21 door Anoniem
Door Anoniem:
Door Anoniem: [...] Waarom zou Google hier zo veel moeite insteken? [...]
Google doet dit omdat ze, in tegenstelling tot Mozilla, er niet voor gekozen hebben om de webbrowser te (her)schrijven in een memory-safe programmeertaal zoals Rust.
Het boeit toch helemaal niet in welke taal de browser geschreven is? Het is de processor waar het hier om gaat.
Je zou je hooguit kunnen afvragen waarom er niet meer voor gekozen wordt om een aparte return- en data stack
te gebruiken, zoals bijvoorbeeld in Forth gedaan wordt. Dit zal wellicht inefficientere code opleveren omdat de processor
al speciale instructies heeft zoals PUSH en POP die je dan niet meer kunt gebruiken, maar ik zou me kunnen voorstellen
dat je BP als data stackpointer en SP als return stackpointer kunt gebruiken in de Intel architectuur.
(die dan dus wijzen naar compleet verschillende memory pages)
06-05-2021, 11:35 door Anoniem
Door Anoniem:
Door Anoniem: Begrijp ik hieruit goed dat de stack in Windows niet beschermd is met canaries?

Stomme vraag.

Sorry, foutje van mij.

Idd, best een beetje stomme vraag, canaries/buffer & stack overflow protection zit al sinds XP/2003 in Windows.
Geen magie, een van de vele methodes om het aanvallers lastiger te maken.
Net als DEP, SEHOP, ASLR, , Guard Pages, Control Flow Guard, etc.
Zie oa:
- https://docs.microsoft.com/en-us/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10#windows-heap-protections
- https://msrc-blog.microsoft.com/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities/
06-05-2021, 11:42 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: [...] Waarom zou Google hier zo veel moeite insteken? [...]
Google doet dit omdat ze, in tegenstelling tot Mozilla, er niet voor gekozen hebben om de webbrowser te (her)schrijven in een memory-safe programmeertaal zoals Rust.
Het boeit toch helemaal niet in welke taal de browser geschreven is? Het is de processor waar het hier om gaat.

Wat de aanvaller wil bereiken is dat de processor een stukje code van de aanvaller gaat uitvoeren .
Dat wordt bereikt doordat data van de aanvaller uiteindelijk als code ergens terecht komt en aangeroepen wordt - bijvoorbeeld doordat het return adres op de stack overschreven wordt met het adres waar de code van de aanvaller staat.

Het soort bugs waarbij stukjes data van de aanvaller rondslingeren op een manier dat ze aangeroepen worden zijn in sommige talen makkelijker te maken dan in andere .

Deze persoon gelooft heel erg dat dat in Rust zodanig onmogelijk is dat om die reden Mozilla niks extras hoeft te doen.
Ik betwijfel of het in Rust (en het hele ecosysteem - de browser linked een berg libraries mee die ook kunnen bijdragen aan vulnerabilities) zodanig onmogelijk is dat deze stack protectie optie _niks bijdraagt_ .
06-05-2021, 11:48 door Anoniem
Door Anoniem: Het is toch wat wat je allemaal moet doen om het onder windows veiliger te krijgen. Vechten tegen de bierkaai. Waarom zou Google hier zo veel moeite insteken? Ze gebruiken zelf helemaal geen windows desktops

Wat is er toch gebeurd met iemand als elk berichtje per se moet worden verdraaid in iets negatiefs over een OS of app?

CET heeft niks met een bepaald OS te maken. Het is een processor-feature en er wordt gewerkt aan Linux support:

https://www.phoronix.com/scan.php?page=news_item&px=Intel-CET-2020-WIP
https://www.phoronix.com/scan.php?page=news_item&px=Intel-CET-v15-Linux-Patches
https://lore.kernel.org/lkml/20190606200646.3951-3-yu-cheng.yu@intel.com/
07-05-2021, 11:51 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: [...] Waarom zou Google hier zo veel moeite insteken? [...]
Google doet dit omdat ze, in tegenstelling tot Mozilla, er niet voor gekozen hebben om de webbrowser te (her)schrijven in een memory-safe programmeertaal zoals Rust.
Het boeit toch helemaal niet in welke taal de browser geschreven is? Het is de processor waar het hier om gaat.

Wat de aanvaller wil bereiken is dat de processor een stukje code van de aanvaller gaat uitvoeren .
Dat wordt bereikt doordat data van de aanvaller uiteindelijk als code ergens terecht komt en aangeroepen wordt - bijvoorbeeld doordat het return adres op de stack overschreven wordt met het adres waar de code van de aanvaller staat.

Het soort bugs waarbij stukjes data van de aanvaller rondslingeren op een manier dat ze aangeroepen worden zijn in sommige talen makkelijker te maken dan in andere .

Deze persoon gelooft heel erg dat dat in Rust zodanig onmogelijk is dat om die reden Mozilla niks extras hoeft te doen.
Ik betwijfel of het in Rust (en het hele ecosysteem - de browser linked een berg libraries mee die ook kunnen bijdragen aan vulnerabilities) zodanig onmogelijk is dat deze stack protectie optie _niks bijdraagt_ .
SElinux enforcing mode aanzetten.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.