Programvare kan være sammensatte og komplekse greier. Dette kan blant annet gjøre det vanskelig både å oppdage og fjerne sårbarheter. Dette vises blant annet ved at leverandøren noen ganger må komme med flere sikkerhetsfikser til én og samme sårbarhet, ofte fordi det etter hvert oppdages flere måter å utnytte den samme sårbarheten på.
Andre ganger greier leverandører å fjerne sårbarheten, men så dukker den på «mystisk» vis opp igjen.
Zombie-sårbarhet
Dette var tilfellet med en sårbarhet som ble fjernet fra Apple Safari i 2013. Sikkerhetsoppdateringen skal den gang har fjernet sårbarheten fullstendig. Likevel ble den utnyttet i angrep i januar i år. Sårbarhetene ble ansett for å være ganske alvorlig siden den åpnet for kjøring av vilkårlig kode.
Det var Googles Project Zero-avdeling som oppdaget den gjenoppståtte sårbarheten. Nylig kom avdelingen med en gjennomgang av det som trolig har skjedd.
Det viser seg fra kildekoden til Webkit-delen av Safari, hvor sårbarheten har opptrådt i implementasjonen av History API, at sårbarheten – som var av typen use-after-free – ble gjeninnført under det som framstår som en omfattende refaktoreringsinnsats, som ble gjort i 2016. Returverdien til HistoryItem::stateObject ble endret fra typen RefPtr og tilbake til en «raw» SerializedScriptValue*-peker, slik det var før sårbarheten ble fjernet i 2013.
Dette er beskrevet med mange flere detaljer i blogginnlegget.
Kan ha blitt utnyttet lenge
Sikkerhetsforskeren Maddie Stone, som har skrevet blogginnlegget, skriver at hun sliter med å forstår hvorfor denne endringen ble gjort.
Google Project Zero vet ikke hvor lenge sårbarheten har blitt brukt i angrep, men det har altså vært mulig å utnytte den fra desember 2016 og fram til den på nytt ble fjernet i januar 2022.
Stone avslutter blogginnlegget med å understreke at slike «zombie»-sårbarheter ikke er noe som er unikt for Safari eller Webkit. Tilsvarende har også blitt funnet flere ganger bare i år i blant annet Google Pixel, Chromium, iOS og Windows.
