Apple lost twee zerodays in iOS 17, iPadOS 17 en macOS op

Apple heeft donderdag een patch uitgebracht voor iOS 17.1.2, iPadOS 17.1.2 en macOS Sonoma 14.1.2 die twee kwetsbaarheden oplost. Deze zitten in de WebKit-browserengine. Het gaat daarbij om een out-of-boundsreadbug en een bug die het geheugen corrumpeert.

In de patchnotes staat dat de kwetsbaarheden de registraties CVE-2023-42916 en CVE-2023-42917 hebben gekregen. Beide zerodays zijn ontdekt en gerapporteerd door Clément Lecigne van Googles Threat Analysis Group.

De zerodays zijn aangetroffen in WebKit. Apple zegt over CVE-2023-42916 dat deze 'bij het verwerken van webinhoud gevoelige informatie kan vrijgeven'. Over CVE-2023-42917 schrijft Apple dat 'het verwerken van webinhoud kan leiden tot het uitvoeren van willekeurige code'. Het bedrijf zegt dat het op de hoogte is van een rapportage over het mogelijke misbruik van de zerodays in iOS-versies voor versie 16.7.1.

Update: Informatie en link over macOS-patch toegevoegd.

Reacties (49)

[PhilipsFan]

Vroegah zaten we te mopperen dat Microsoft probeerde om Internet Explorer te integreren in Windows. Microsoft deed het om de verkeerde redenen, maar er zat wel een grond in dat bezwaar. Het heeft in het verleden ook grote beveiligingsproblemen opgeleverd voor Windows.

In IOS gebeurt hetzelfde. Waarom levert Apple Safari niet gewoon als een losse, maar wel voorgeinstalleerde app? Dat is veel makkelijker te updaten. Ik ken talloze mensen die met een verouderde versie van IOS rondlopen terwijl hun toestel gewoon een nieuwere aankan. Te weinig tijdelijke opslagruimte, geen zin, geen tijd, bang dat een update fout gaat of functionaliteit verwijdert. Terwijl Safari meermaals de oorzaak is van zerodays. Suggestie, Apple? Koppel die los van elkaar en lever Safari als een normale app.

[Maurits van Baerle]

Safari maakt gebruik van Webkit maar WebKit op iOS is een operating system library terwijl Safari een app is.

Je zou dus wel een nieuwe Safari kunnen pushen via een app update maar daarmee is WebKit nog niet vervangen. En deze zerodays zaten niet in Safari maar in WebKit.

En system libraries vervangen via app updates is vragen om problemen. Microsoft deed dat vroeger wel met IE. Installeerde je een nieuwe versie van IE en werkte je OS ineens anders omdat de onderliggende libraries vervangen waren. Het was een apart soort dependency hell.

Dan is het betrouwbaarder (en mogelijk makkelijker te testen op regressions) om gewoon kleine fixes van het OS uit te brengen om problemen in system libraries op te lossen.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 13:31]

[Ed Vertijsment]

Het is natuurlijk wel zo dat Apple andere renderers verbied in IOS , terwijl het prima mogelijk zou zijn. Dan zou je niet verplicht zijn webkit te gebruiken.

[PhilipsFan]

Maar een library om een webpagina te renderen hoort ook helemaal niet in het OS. Als het OS een webpagina wil openen, dan moet het gewoon doen wat een normale gebruiker ook doet: de webbrowser openen!

[Maurits van Baerle]

Zo werkt dat ook op iOS, een webpagina wordt geopend in wat de gebruiker als standaardbrowser heeft ingesteld.

Maar, HTML renderaars worden niet alleen voor het browsen van wegpagina's gebruikt. Er word ook op een heleboel andere plekken HTML gebruikt (volgens mij is bijvoorbeeld de App Store weliswaar een lokale app maar wordt de content met HTML vormgegeven) en daar is WebKit op iOS prima voor geschikt.

[ashwin911]

Volgens mij is WebKit in het OS geïntegreerd omdat ze eerst van plan waren om apps op de iPhone via web apps te doen. Steve Jobs wou eerst helemaal niet de iPhone open stellen voor native 3rd party apps.

[Mantis]

Op Android wordt de System WebView gewoon geüpdatet via de store zonder problemen.

[lenwar]

Al zou Safari verwijderbaar zijn, dan behoud je nog wel de noodzakelijkheid van Webkit. Webkit is het mechanisme dat door vele andere apps gebruikt wordt (danwel gebruikt moet worden) om web-zaken te regelen.
Veel apps zijn in de praktijk weinig meer dan een schilletje van een website, die bruikbaar wordt door de Webkit engine. (Zie bijvoorbeeld ongeveer 100% van de webwinkel-apps en forum/community-apps)

Al zou Safari verwijderbaar zijn, of zelfs helemaal niet meegeleverd worden, zou het raar zijn als iOS niet Webkit meelevert. Anders zouden alle app-makers zelf, of een web-library (met alle beveiligingsissues) moeten maken, of zelf Chromium/Webkit/Gecko/enz. moeten meeleveren. En dan is het maar te hopen dat ze hem ook een beetje updaten, want iedere web-engine heeft eens in de zoveel tijd bekende beveiligingsproblemen.

(Onderdelen van) Webkit wordt ook binnen het OS gebruikt om allerlei zaken binnen het OS te regelen. Safari is een van de apps die Webkit gebruiken.

Deze patches (zoals beschreven in dit artikel) zijn dan ook Webkit-problemen, niet Safari-problemen. Firefox/Chrome/enz. browser gebruikt ook Webkit op iOS (uiteraard omdat het moet).
Op dezelfde manier kan je ook prima Facetime-gesprekken voeren, zonder de Facetime-app. De libraries die nodig zijn voor videobellen zijn een onderdeel van het iOS.

[klonic]

Dat zou maar een deel van het probleem oplossen, want Apple stopt gewoon met updates na een jaar of 6 tot 10. Idealiter laten ze dus ook alternatieve browser engines toe. In IOS draait namelijk elke browser op webkit. (Dus ook Brave, Chrome etc).

Misschien is dit nu niet maar maar tot een jaar of 5 geleden was dit wel zo. Wat bij slecht renderen van websites heel irritant is.

[Reactie gewijzigd door klonic op 24 juli 2024 13:31]

[PhilipsFan]

Slecht renderen ligt eigenlijk altijd aan de website, maar ik zie dat nog maar zelden. Ik zou geen reden kunnen verzinnen waarom ik een andere browser engine zou willen.

Apple stopt bij de meeste iPhones na 6 jaar met updates van het besturingssysteem (wat langer is dan alle andere fabrikanten), maar als er echt gevaarlijke zerodays worden gevonden, dan worden die ook gepatched in oudere IOS versies.

[arjan1995]

Yes, ios 16 krijgt bijvoorbeeld nu nog beveiligingsupdates, en mogelijk ios 15 ook. Al lijkt deze bug al gepatcht, omdat ze het in de laatste zin hebben over tot 16.7.1, terwijl 16.7.2 al uit is

[Matthijs8]

Zoals ik het lees betekent het alleen maar dat de lekken toen al misbruikt werden. Nu is het pas gefikst.
Als je de 16.7.0 ,.1 en .2 updates opzoekt, wordt CVE-2023-42916 ook helemaal niet vermeldt. Oudere iOS versies krijgen vaak pas later een update, dus voor 16 komt er waarschijnlijk de komende weken een update.

[StGermain]

Ik hoop het want mijn iPhone X is dus niet veilig op dit moment al is dat relatief want buiten tweakers, mijn krant en sporza gebruik ik internet er toch niet op maar het gaat me om het principe dat een apparaat wat nog perfect mee kan qua snelheid ook al is het zes jaar oud gewoon veilig moet kunnen blijven. Waarom kunnen we dit wel met computers en niet let apparaten die haast even duur zijn?

[kevinkrs]

Dit is het halve verhaal. Apple brengt nog regelmatig kritische beveiliging updates uit voor niet meer ondersteunde toestellen. Uiteraard zit wel overal een eind aan. Als je nu nog met een iPhone 4 rondloopt denk ik niet dat je nog security updates krijgt, maar jij als eindgebruiker zelf ook niet veel om security geeft.

Wat Apple doet vind ik juist fijn, gewoon 1 browser, 1 notitie app, 1 mail app meeleveren. Als je een andere wilt gebruiken (hetzij dan via dezelfde Webkit) kun je deze gewoon downloaden in de Store. Dit maakt dingen zoveel simpeler. Vanuit mijn gebruikerservaring loopt alles via de Webkit van Apple ook gewoon vloeiend, terwijl ik op Android in veel apps incl. Google Chrome bij het scrollen veel stoteringen zie.

Eind goed al goed zeg ik dan maar, Apple heeft wel vrij rap een fix uitgebracht, dat is het belangrijkst.

[Luminair]

Apple heeft wel vrij rap een fix uitgebracht

Dat is een goed punt, wat naar mijn idee in deze discussie verloren is gegaan: die zero-day, die werd dus wel gewoon snel gepatched-- ondanks dat het met een OS update ging. (Het zou sneller kunnen, zonder reboot, met een Rapid Security Response, maar die deden ze nu raar genoeg niet?)

Naar mijn idee wil Apple niet dat "het wordt sneller geüpdatet als het een losse browser-update was"-argument ontwapenen daarmee. Want hoeveel sneller hadden Firefox en Chrome hun update uitgebracht?

[beerse]

Een klein maar significant verschil tussen webkit en safari is dat webkit de centrale code/librarie is om webpagina's en zo in beeld te zetten. Safari is een browser die daar gebruik van maakt. En op de mobiele apple apparatuur is het volgens mij verplicht om webkit te gebruiken dus gebruiken alle browsers en alle web-apps dat.

Gelukkig is het updaten/bijwerken van ios niet zo veel werk. Het is een stevige download die rustig binnen komt. Daarna uitpakken, herstarten en weer door.

[maanvaren]

Apple is een bedrijf dat rationeel met zijn gebruikers omgaat om zijn winst op peil te houden.
Iphone X kon je 5-6 jaar gelden kopen. IOS17 wordt niet ondersteund dus dit niet en dat en ook niet de nieuwste safari en firefox/brave/chrome want die worden alllemaal verplicht om webkit te gebruiken.
Safari is ook de enigste*(2022) die fullscreen en canvas (voor games) kan gebruiken. Stel dat Safari een losse app zou zijn dan wordt het argument van oneerlijke concurrentie tov die andere browsers aantoonbaarder. Safari/webkit zijn zeer belangrijk om te verhinderen dat de chrome of firefox engine een alternatief wordt voor de appstore.

[Skywalker27]

Security updates komen nog steeds uit voor IOS16.

[Roel1966]

Dat is toch wel handig als je op Tweakers zit dat je altijd even kan checken of er niks mis is met een update, iets wat ik altijd wel doe alvorens die te installeren. Maar inderdaad, genoeg iPad gezien waar mensen updates gewoon negeren en denken van ja ach, is niet belangrijk.

Of het een oplossing is om Safari los te koppelen, tja, diezelfde mensen zullen dan denk ik Safari weer gewoon installeren omdat ze niet beter weten. Om daarna vervolgens ook weer updates te negeren en je dan toch weer terug bij af bent.

[PhilipsFan]

Maar een update van een app gaat veel makkelijker dan een update van IOS. Je telefoon hoeft niet te herstarten, het kan gewoon in de achtergrond gebeuren. De meeste mensen hebben voor apps automatische updates aan staan. Veel veiliger.

[Roel1966]

De meeste mensen hebben voor apps automatische updates aan staan. Veel veiliger.

Voor beveiliging mischien wel ja maar niet altijd werken updates goed uit en kunnen ook juist voor problemen zorgen. Om die rede dat ik automatisch updaten uit heb staan op zowel de telefoon als op de pc.

[CorbataGames]

Hetzelfde geldt volgens mij ook voor MacOS.

[dutch_mentor]

Yes, zie ook deze link: https://support.apple.com/nl-nl/HT214032

[LFranxWind]

Bedankt voor het doorgeven! Ik heb het toegevoegd aan het artikel

[MrBreaker]

Waarom is er geen update voor de WatchOS aangezien dit een probleem in webkit betreft? 🤔

[Milmoor]

Je zou toch verwachten dat er inmiddels programmeertalen of ontwikkelomgevingen zijn waar je kan aangeven wat het werkgebied van de code is. Dat zal extra overhead leveren, maar we hebben best wat meer power dan vroeger. Sandboxen binnen de code. *

* Deze opmerking is niet getoetst op daadwerkelijk onderzoek en is puur schieten vanaf de heup.

[bzzzt]

Zo'n artikelkop probeert het security probleem voor normale mensen begrijpelijk te maken. Dat betekent niet dat het probleem triviaal is.
Volgens die macOS note is er memory corruptie die door betere locking is opgelost. Dat betekent dus dat er sprake is van foutief afhandelen van multithreaded code. Dat kan echt een heel subtiele bug zijn en is in de meeste gangbare programmeertalen lastig te doorzien.

Moderne talen, bijvoorbeeld Rust proberen met extra constructies dit soort controles al bij het compileren plaats te laten vinden en slagen daar deels in. Ook in Rust rewrites van software zijn al CVE waardige bugs gevonden.

[arnoldus1955]

- Garbage collector (Python, Java, etc)?

- Rust / Nim / Zig (option types)?

[joost00719]

Die zijn er ook, maar die gebruiken een stuk meer resources. Dus meer memory en meer CPU, en het is trager.

[sdziscool]

Je kan best aangeven waar de code mag zijn, maar hoe ga je checken dat het er niet buiten komt? Dan zou je of alle plekken buiten de code moeten checken of je moet constant in de gaten houden waar je pointer is(aka elke jump checken waarnaartoe, dat gebeurt best vaak). En zelfs dan hoort de pointer vaak buiten de code te komen (text input gaat via buiten de code, want de usb controller zit niet in jou code) dus welke exits van de code zijn dan goed en welke slecht? Moet je ook weer checken.

Het kan (bijna) allemaal hoor, maar op gegeven moment ben je je checks aan het checken en voor iedere extra stap die je zet zijn er meer dingen die fout kunnen gaan! Dus dan moet je gaan bewijzen dat het niet fout kan gaan.

Dit is gebeurt voor een aantal IBM mainframes die voor bankieren gebruikt werden, die waren "theoretisch bewezen" 100% veilig, dat naam meerdere jaren om te bewijzen en zorgde voor zoveel operationele overhead dat banken ze niet meer konden aanpassen (elke nieuwe aanpassing betekent overnieuw bewijzen dat alles veilig is) ze vierden groots feest toen de laatste bij ING eindelijk uit de lucht werd gehaald een paar jaar geleden.

[jmvdkolk]

Dit is gebeurt voor een aantal IBM mainframes die voor bankieren gebruikt werden, die waren "theoretisch bewezen" 100% veilig, dat naam meerdere jaren om te bewijzen en zorgde voor zoveel operationele overhead dat banken ze niet meer konden aanpassen (elke nieuwe aanpassing betekent overnieuw bewijzen dat alles veilig is) ze vierden groots feest toen de laatste bij ING eindelijk uit de lucht werd gehaald een paar jaar geleden.

Ik denk dat het iets subtieler ligt. ING is nl. één van de weinige grote banken die het mainframe uitgezet heeft. Ik kom regelmatig over de vloer bij de mainframe beheerders van grote banken en daar wordt nog heel veel aangepast, tegenwoordig is ook DevOps op veel plekken binnen het mainframe doorgevoerd.

[Reactie gewijzigd door jmvdkolk op 24 juli 2024 13:31]

[Zezura]

We zitten met veel legacy code, en niet elke programmeur maakt gebruikt van de laatste nieuwe ontwikkelingfuncties.

Code herschrijven is niet zo makkelijk. Gebruik zelf ook nog niet de nieuwste C++ overal.

[Blokker_1999]

Het is simpelweg niet mogelijk om code te schrijven die geen fouten bevat. Gemiddeld genomen zitten er 10 fouten in elke 1000 lijnen code. Als het om meer kritische software gaat ga je naar 5 fouten per 1000 lijnen en zelfs voor zeer kritische software, denk projecten zoals de Space Shuttle heb je uiteindelijk 1 fout per 1000 lijnen. Daar hebben we nu eenmaal mee te leven.

Alle eenvoudige manieren om fouten tegen te gaan worden al lang en breed toegepast, maar ook in al die bescherming die we inbouwen kunnen nu eenmaal fouten zitten die opgelost moeten worden.

[XavierIT]

Klopt!

[swtimmer]

Ik had ook last dat mijn klok/datum niet meer goed stond. Dat lijkt in deze ook weer gewoon goed automatisch te werken.

[MiesvanderLippe]

Vroeger, toen het gras nog groen was en jailbreakme.com werkte

[MrUnknown1898]

Toch best bijzonder dat twee zero days 300+MB is als update bestand en mijn iPhone 13 daar 10 minuten mee bezig is..

[Hackus]

Toch best bijzonder dat twee zero days 300+MB is als update bestand en mijn iPhone 13 daar 10 minuten mee bezig is..

Niet alleen dat

[DR!5EQ]

Betreffende CVE-2023-42916:
Ik miste nog dat deze zero day ook al aanwezig was voor iOS en iPadOS 17.1 en macOS 14.1.

Apple is aware of a report that this issue may have been exploited against versions of iOS before iOS 16.7.1.

Bron: https://www.cve.org/CVERecord?id=CVE-2023-42916

Nu dus echt reden om te upgraden (daargelaten dat er mogelijk eerder zero days zijn gevonden waar ik niet van op de hoogte ben).

[Hackus]

Betreffende CVE-2023-42916:
Ik miste nog dat deze zero day ook al aanwezig was voor iOS en iPadOS 17.1 en macOS 14.1.

Apple is aware of a report that this issue may have been exploited against versions of iOS before iOS 16.7.1.

Bron: https://www.cve.org/CVERecord?id=CVE-2023-42916

Nu dus echt reden om te upgraden (daargelaten dat er mogelijk eerder zero days zijn gevonden waar ik niet van op de hoogte ben).

Dat is al gefikst. iOS 16.7.2 is er al sinds 10 okt, en 16.7.1 nog eerder

[Matthijs8]

Zoals ik het lees betekent het alleen maar dat de lekken toen al misbruikt werden. Nu is het pas gefikst.
Als je de 16.7.0 ,.1 en .2 updates opzoekt, wordt CVE-2023-42916 ook helemaal niet vermeldt. Oudere iOS versies krijgen vaak pas later een update, dus voor 16 komt er waarschijnlijk de komende weken een update.

Overigens is 16.7.1 er sinds 10 oktober, .7 is er pas sinds 2 oktober.

[Ed Vertijsment]

Ik heb nog een iPhone 8, kan niet updaten naar iOS 17 en staat nog op 16.6.1. Krijg ik nog een beveiligingsupdate of kan ik nu puur voor dit beter een nieuwe telefoon kopen?

[webhalla]

Beste Ed,

Kijk gewoon altijd even op de volgende pagina van Apple wanneer er weer updates zijn: https://support.apple.com/nl-nl/HT201222

Dat het nieuwste besturingssysteem niet meer gedraaid kan worden op oudere toestellen, betekend niet dat apple voor oudere toestellen geen beveiligingsupdates meer maakt. Vaak zijn de updates noodzakelijk voor de nieuwe toestellen en de nieuwe apps.

Sorry dat dit geen excuus is om een iPhone 15 onder de kerstboom te vinden

[Ed Vertijsment]

Er is nog hoop dus? Top want mijn 8 doet het op zich nog prima

[Matthijs8]

Oudere versies krijgen vaak later updates. Bij recente 0day fixes van oktober kwam er 6 dagen later een update voor iOS 16.
Als je overigens echt nog op 16.6.1 zit zou ik direct updaten, dan heb je 16.7.0, 16.7.1 en 16.7.2 gemist. Allen fixen security issues en 2 van de 3 updates ook 0days.

[Reactie gewijzigd door Matthijs8 op 24 juli 2024 13:31]

[Ed Vertijsment]

Ah beta updates stond aan, kreeg daardoor geen update, nu maar updaten naar 16.7.2

Thx all!