image

Apple herintroduceerde Safari-zeroday door refactoren van code in 2016

woensdag 15 juni 2022, 17:08 door Redactie, 7 reacties

Begin dit jaar kwam Apple met een beveiligingsupdate voor een actief aangevallen zerodaylek in Safari voor iOS en macOS. Het beveiligingslek, aangeduid als CVE-2022-22620, was in 2013 al een keer door Apple verholpen, maar in 2016 geherintroduceerd bij het refactoren van de code. Dat laat Google op basis van een analyse weten.

Het beveiligingslek was aanwezig in WebKit, de door Apple ontwikkelde browser-engine. Alle browsers op iOS en iPadOS zijn verplicht om van WebKit gebruik te maken. Door het verwerken van malafide webcontent ontstaat er een "use after free" kwetsbaarheid en is het uitvoeren van willekeurige code op het systeem mogelijk. Hiervoor is geen interactie van de gebruiker vereist, behalve het bezoeken van bijvoorbeeld een compromitteerde website. Dit wordt ook wel een drive-by download genoemd.

Volgens Google komt het vaak voor dat softwareontwikkelaars kwetsbaarheden niet volledig patchen, waardoor aanvallers op een iets andere manier misbruik van een beveiligingslek kunnen maken. In dit geval kwam Apple begin 2013 met een patch voor de kwetsbaarheid. Die was zo grondig dat alle mogelijke paden voor misbruik werden verholpen. In 2016 besloot Apple de betreffende code te refactoren. Dit is het opschonen en updaten van code.

Hierbij werd de kwetsbaarheid opnieuw geïntroduceerd en bleef tot begin van dit jaar onopgemerkt, toen aanvallers er actief misbruik van maakten en Apple een update uitrolde. Hoelang aanvallers misbruik van het WebKit-lek hebben gemaakt is onbekend. "Maar we weten dat de kwetsbaarheid opnieuw vijf jaar lang heeft bestaan: van december 2016 tot januari 2022", zegt Maddie Stone van Google Project Zero.

Ze merkt op dat er geen eenvoudig antwoord is voor wat Apple anders had kunnen doen. De initiële bug werd namelijk grondig verholpen. Volgens Stone is het probleem niet uniek voor Safari. "We hebben actief aangevallen zerodaylekken gezien die varianten van eerder onthulde kwetsbaarheden in Chromium, Windows, Pixel en iOS waren. Het is een goede reminder dat we als verdedigers alert moeten blijven bij het reviewen en auditen van code en patches."

Reacties (7)
15-06-2022, 18:45 door Anoniem
Project Zero

Geef een project een obscure naam en security mensen krijgen een fijn gevoel in hun broekje.
15-06-2022, 19:22 door buttonius
Er is wel een eenvoudig manier om te voorkomen dat eerder verholpen bugs kunnen terugkeren.

Het goed repareren van een bug begint met het schrijven van een unit test die bewijst dat de bug niet aanwezig is.
Toegepast op de nog niet gerepareerde software faalt deze test.
Daarna verhelp je de bug.
Tenslotte gebruik je de unit test om te bewijzen dat de bug verholpen is.

De nieuwe unit test hou je (voor altijd) in je test suite. Mocht de bug bij een latere update per ongelijk terugkeren, dan zal deze unit test 'm detecteren.
15-06-2022, 20:55 door Anoniem
Regressie testen is erg lastig voor grote bedrijven, zeker als je opdra ht krijgt uit de nsa om hun snoepje weer terug te brengen..
15-06-2022, 21:15 door Anoniem
Door Anoniem: Project Zero

Geef een project een obscure naam en security mensen krijgen een fijn gevoel in hun broekje.

Het is gewoon een naam met een getal… ik denk dat dat fijne gevoel in je broekje gelimiteerd is tot jou broekje. Ik voel namelijk niks bij zero.
15-06-2022, 23:38 door Anoniem
En wat gaat Google structureel doen aan het vergiet dat Chrome heet?
15-06-2022, 23:55 door Anoniem
Volgens Google komt het vaak voor dat softwareontwikkelaars kwetsbaarheden niet volledig patchen
Het grote Google moet toch eerst zelf maar zijn zero-days aanpakken alvorens iemand de maat te nemen.
18-06-2022, 13:07 door Anoniem
Door Anoniem:
Volgens Google komt het vaak voor dat softwareontwikkelaars kwetsbaarheden niet volledig patchen
Het grote Google moet toch eerst zelf maar zijn zero-days aanpakken alvorens iemand de maat te nemen.
Je weet ook dat google de diagnostische analyse uitvoert als je dat aanvinkt in Mac OS??
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.