Apple dicht zeroday in iOS met beveiligingsupdate 14.4.2

Apple heeft vrijdag update 14.4.2 uitgebracht voor iOS die een kwetsbaarheid dicht in WebKit. De kwetsbaarheid is aangetroffen in iOS en iPadOS. Het is de tweede beveiligingsupdate voor iOS deze maand.

De kwetsbaarheid CVE-2021-1879 is ontdekt door Clement Lecigne en Billy Leonard van de Google Threat Analysis Group. Volgens Apple werd de kwetsbaarheid actief misbruikt.

Het gaat om een lek in WebKit en hierdoor was 'cross-site scripting' mogelijk. Verder wil Apple nog niets zeggen over het beveiligingslek totdat het zijn eigen onderzoek heeft afgerond.

De update is beschikbaar voor iPhone 6s of nieuwer, alle iPad Pro-modellen, iPad Air 2 en nieuwer, iPads van de vijfde generatie of nieuwer, iPad Mini 4 of nieuwer en de iPod Touch van de zevende generatie.

Ook Apple-apparaten die nog iOS 12 hebben, krijgen de beveiligingsupdate. Update 12.5.2 is te downloaden voor iPhone 6, iPhone 5s, iPad Mini 3, de eerste generatie iPad Air en de zesde generatie iPod Touch.

Eerder deze maand bracht Apple ook al een update uit voor iOS. Update 14.4.1 dichtte een lek in webbrowser Safari. Apple gaf verder geen details over de beveiligingsupdate.

Reacties (55)

[PhoenixT]

iOS 12 heeft de patch ook gehad, dus de patch is er ook voor iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3 en iPod touch (6th gen).

[macfreak1306]

Je was me net voor
Tevens klopt het artikel niet helemaal. De iOS 14 update is alleen voor iPhone 6s of nieuwer, de gewone 6 krijgt de iOS 12 update.

[Robert Zomers]

Dankjewel! Ik heb de informatie over iOS 12 toegevoegd.

[macfreak1306]

Opvallend om te zien dat iOS 12 de update ook heeft gekregen voor de oudere toestellen. Blijkbaar vond Apple de bug ernstig genoeg om ook deze niet langer ondersteunde modellen toch te updaten.

Het artikel klopt overigens niet helemaal. De iOS 14 update is alleen op de iPhone 6s of nieuwer. De iPhone 6 en lager hebben geen ondersteuning voor iOS 14 en krijgen dus de iOS 12 update.

[Keypunchie]

Blijkbaar vond Apple de bug ernstig genoeg om ook deze niet langer ondersteunde modellen toch te updaten.

Ze rapporteren exploits "in the wild".

Deze patch is behoorlijk "out of schedule". Noem het paranoia, maar volgens mij is er iets aan de hand. Je zou eerder 14.5 verwachten, dus ik heb ook maar snel mensen die ik ken met een iPhone/iPad aangeraden om deze snel te installeren.

Voor dit soort bugs geldt volgens mij ook een soort van 'herd immunity' principe. Als er genoeg mensen de patches installeren, dan zullen er minder groepen zijn die exploits proberen te schrijven en/of uitvoeren.

Door de patch zo breed beschikbaar te maken, wil Apple zo breed mogelijk bescherming bieden.

[Reactie gewijzigd door Keypunchie op 27 juli 2024 09:41]

[pBook]

Apple zal nooit een relatief grote release als 14.5 op vrijdag de deur uit doen. Die staat gepland voor het volgende event met nieuwe iPad Pro’s etc.

[Keypunchie]

Apple released ‘normale’ updates praktisch altijd aan het begin van de week.

Ik bedoel vooral: 14.5 is behoorlijk rijp (bèta’s zijn al heel ver), als het een kleine bug was, dan had Apple hem daarin gerold, want die kan ieder moment uitkomen.

Het feit dat Apple daar niet op wacht is een teken dat er iets bijzonders aan de hand is met deze bug.

[Reactie gewijzigd door Keypunchie op 27 juli 2024 09:41]

[Dennisdn]

Voor de 14.5 Beta zie ik ook geen extra update verschijnen. Dus óf de update is al verwerkt in de beta van vorig weekend óf de release is echt dichtbij en voor die laatste paar dagen laten ze het zo.

[TheVivaldi]

"Opvallend om te zien dat iOS 12 de update ook heeft gekregen voor de oudere toestellen"

Is dat opvallend? Ik dacht dat Microsoft ook nog 1 of 2 updates had uitgerold voor Windows XP nadat de ondersteuning was afgelopen. Komt dus wel vaker voor. Wel netjes, overigens

[Reactie gewijzigd door TheVivaldi op 27 juli 2024 09:41]

[jcbvm]

Op zich goed dat ze de patch uitleveren, ik vraag me alleen altijd af hoelang het dan duurt voordat gebruikers deze ook echt hebben geïnstalleerd. De melding van een update komt pas vaak dagen of weken later en ik ken mensen die gewoon bijna nooit updaten of er naar omkijken.

[Cybertinus994]

Ik gebruik Duo als mijn 2FA TOTP app. Die geeft een alert als mijn iOS versie achter loopt. Zo heb ik zowel 14.4.1 als 14.4.2 opgemerkt, binnen 24 uur na de release. Fijne feature van die app

[E - man]

Verbaast me eigenlijk niets dat er een update komt, had al een gevoel dat er iets helemaal niet goed was na de laatste update. Vreemde crashes in Safari bij gebruik van Youtube. Ene moment zit je een video te kijken, opeens zwart beeld met spinner en terug op lock screen. De error logs leken iets aan te geven over geheugenproblemen, maar weinig details.

[Marcel3X]

Daar heeft deze update niets mee te maken...

[E - man]

Zat een bug in Webkit, zijn verder niet echt details, behalve dat het misbruikt kon worden. Zou zomaar kunnen dat het ook voor memory leaks zorgde. Een herstart van de telefoon loste het probleem namelijk niet op en was echt pas gekomen na 14.4.1, die ook een update voor Webkit bevatte. Sinds 14.4.2 is het probleem weer weg.

[Marcel3X]

Oké 👌

[jmvdkolk]

Mijn zoon zijn iPad Mini (iOS 12.2) geeft aan dat zijn iPad up-to-date is. Dit terwijl de iPad al tijden niet geupdate is. Hoe kom je aan deze beveiligingsupdate voor iOS 12?

Edit: aansluiten op mijn MacBook hielp. Nog een lesje updates nodig hier. Dacht ten onrechte dat dat niet meer nodig was.

[Reactie gewijzigd door jmvdkolk op 27 juli 2024 09:41]

[jmvdkolk]

Ik ben bang dat de visie van Steve Jobs al een tijdje niet meer doorgezet wordt. Tim Cook is vooral heel goed in productie processen optimaliseren, en dan vooral hardware. Volgens mij merken we dit door gebrek aan visie en gebrek aan kwaliteit in de software. Ooit, lang gelezen, kocht ik Apple apparaten omdat ze het simpelweg doen. Inmiddels is dat helaas alweer even geleden. iOS, iPadOS en MacOS zitten vol met stomme fouten waar we allemaal mee leren leven. Er is allemaal nieuw slimme integratie gebouwd tussen de diverse systemen die het soms doet maar soms ook niet. Het gaat meestal niet om de kern, dus de belangrijkste dingen doen het nog wel. Bij de beta's van iOS 14.5 zie je nu dat er gevraagd wordt (in fora) om de beta maar te releasen terwijl er nare known issues in zitten. De nieuwe verbeteringen zijn voor veel gebruikers belangrijker dan de kleine kans dat je last hebt van zo'n known issue.

Allemaal prima om mee te leven als het systeem dan beter is dan de concurrentie en in ieder geval veiliger en meer privacy geeft. Qua privacy heeft Apple echt nog een voorsprong. Maar qua veiligheid al even niet meer. Google heeft Apple al lang ingehaald op dat gebied. Nog even, en je koopt alleen een Apple voor privacy en accepteert dat het verder inferieur is. En als de veiligheid niet meer goed genoeg is, dan is privacy ook een illusie. Ik hoop dat het niet zo ver komt maar ik heb er een hard hoofd in ......

[JackBol]

Ik vraag me af hoe je tot die conclusie komt. Dat er bugs in een product zitten, is niet te voorkomen. Hoe snel die opgelost worden zegt iets over de commitment van de fabrikant. Alle kritische bugs worden in Apples software snel opgelost.

[jmvdkolk]

Ik kom tot die conclusie door ervaring van mijzelf en mensen om mij heen. De hoeveelheid glitches waar ik last van heb is de afgelopen jaren enorm toegenomen. Het zijn zelden kritische bugs, maar ze zitten wel in de weg en worden niet of langzaam opgelost.

Een kleine selectie van niet kritische issues van de afgelopen jaren:
1. Automatische updates van iOS en iPadOS. Het heeft bij mij 1 1/2 jaar geduurd voordat er voor het eerst een update automatisch werd geinstalleerd. Hier in huis hebben we 7 iOS/iPadOS apparaten, en geen enkele installeerde gedurende die 1 1/2 jaar ooit een automatische update. Sinds enige tijd doen automatische updates het op 1 van de 7 apparaten.
2. Ik kan mijn MacBook unlocken met mijn Apple Watch. Afgelopen najaar stopte dit spontaan. Sommigen vonden workarounds (ik ook) en anderen hebben nog steeds last van dit issue. Na toepassen van een workaround werkte het in eerste instantie niet altijd. Zonder ergens een update geinstalleerd te hebben werkte het vanaf een bepaald moment weer altijd.
3. Als ik op mijn iPad inzoom in een foto, switch van app, en weer terug ga naar de foto's app, dan moet ik van foto wisselen voordat ik opnieuw kan inzoomen op alle delen van de foto. Dit probleem zit er al sinds iOS 11 in en Apple vindt het niet boeiend.
4. De widget bar op mijn iPad is regelmatig leeg. Als ik scroll in de bar, dan komen de widgets vaak weer terug, maar niet altijd. Gelukkig komen ze altijd uiteindelijk terug.
5. Op mijn Apple Watch heb ik een playlist ingesteld staan die af gaat spelen als ik een workout start. De bedoeling is (en zo staat het ingesteld) dat deze playlist alleen gaat afspelen als ik niet al luister naar een andere playlist of podcast. Met enige regelmaat wordt de instelling genegeerd en start mijn workout playlist alsnog op.

Ik kan nog een tijdje doorgaan. Allemaal luxe problemen, maar veel kleine issuetjes tellen uiteindelijk op. En mijn persoonlijke ervaring is dat er sinds iOS/iPadOS 13 en sinds MacOS Catalina meer van dit soort issuetjes zijn die ik opmerk. Dit geeft voor mij aan dat er minder aandacht voor kwaliteit is dan voorheen. Het is mijn persoonlijke ervaring, en de ervaring van anderen kan anders zijn.

[cold_as_ijs]

grrr, fijn dat dit opgelost is maar wacht nu al een tijdje op 14.5. Hoopte dat deze eind februari zou komen ondertussen zijn we al een maandje later. Blijf nog maar even wachten

[swhnld]

Dit soort beveiliging updates komen door de planning heen lopen en moeten ze dubbel oplossen, in de huidige en in de toekomstige software, en daardoor loopt die toekomstige versie verder uit. Belangrijkste echter is de beveiliging, dus goede prioriteit door Apple.

[fapkonijntje]

Ontzettend dom eigenlijk dat dat moet omdat webkit/Safari in het OS verweven zit. We zijn massaal aan het klagen geweest toen MS dat met internet Explorer deed en Apple doet dat even dunnetjes over.

Ook op Android kan dit gewoon via een play store update, zo kan het altijd tussendoor zonder issues. Maar bij Apple moet het hele OS bijgewerkt worden.

[Reactie gewijzigd door fapkonijntje op 27 juli 2024 09:41]

[swhnld]

Ik ben het helemaal met je eens dat de reden dat het hele OS geupdate moet worden komt doordat het qua architectuur niet goed opgezet is. Uiteindelijk was het oorspronkelijk bedoeld voor een iPod muziekspeler, en daar werd steeds meer aan toegevoegd.
Andere partijen als Windows en Android hebben in de diverse iteraties hun besturingssystemen aangepast dat je steeds meer kan bijwerken zonder het hele OS te vervangen. Door die ontwikkeling zie je dat een speler als Samsung nu 3 versie upgrades en 4 jaar veiligheidsupdates garandeert en een van de snellere partijen is die die updates en upgrades uitbrengt. Zij maken optimaal gebruik van een deel van de verbeteringen. Bij Windows zie je amper nog een BSOD voorbijkomen nadat ze de HAL geïntroduceerd hebben en uiteindelijk verplicht gemaakt. Zowel Android als Windows ondersteunen een enorme gediversifieerde massa hardware, en het werkt, waar het bij iOS beperkt blijft tot enkele apparaten.
De vraag is echter of Apple dit systeem wil aanpakken, het geeft een veel sterkere vendor lock-in dan wanneer zaken makkelijker uitwisselbaar zijn, en het kost tijd en geld om te ontwikkelen, met als belangrijkste ook een visie, en voor mijn gevoel is het enige wat nu gebeurt bij Apple is de visie van Steve Jobs doorzetten (wat op zich prima is voor de inkomsten van het bedrijf en de vele tevreden klanten), maar ik zie niets echts radicaals gebeuren. Betekend overigens niet dat er niets gebeurt, je weet nooit wat er achter gesloten deuren gedaan wordt, maar we zien of horen er nog niets van.

[fapkonijntje]

Als Apple wil blijven doen alsof ze het veilige alternatief zijn voor Android zullen de rigoureus moeten veranderen. Waar Google heel hard gewerkt heeft met Samsung en andere Androidgebruikers aan het verbeteren van de veiligheid, is iOS nog steeds zo'n beetje hetzelfde. Met inderdaad hier en daar een extra feature. Het gesloten karakter gaf initieel een voorsprong, toen Android te open was, maar die situatie is met Android 6 en verder heel hard aangepakt. Zodoende is het nu Apple die is gaan achterlopen.

Qua veiligheid zijn ze nog 'beter' in de publieke opinie en bij de hard core fans, maar technisch is dat allang niet meer zo. Het is nu daadwerkelijk veel moeilijker om in te breken op een Samsung dan op een iPhone. Hoe onwaarschijnlijk dat ooit was. Maarja zoals je hier ook in de reacties ziet, er zijn er genoeg die de architectuurproblemen en het harde werk van Google niet kennen en zo nog feiten van heel wat jaar geleden blijven herhalen alsof er niets anders is.

Verandering is altijd moeilijk voor mensen, maar toch, we hebben het hier wel over reële risico's waar op basis van gevoel beslissingen over worden genomen of meningen worden gevormd. Dat kan weleens gevaarlijk zijn, want een Apple voelt zich niet geroepen om de situatie te verbeteren. Mensen geloven niet dat iOS zo'n zwakte kent of ze bagetalliseren het met de gekste argumenten en de publieke opinie loopt ook gemiddeld 10 tot 20 jaar achter in de IT.

[swhnld]

Klopt helemaal.

[fapkonijntje]

Wat?

[kamerplant]

Belangrijk detail: internet explorer was (en is) een ontzettend slecht product, wat geen enkel respect had voor internet standaarden. Dat geldt niet voor Safari/WebKit.

[fapkonijntje]

Dat geld wel voor safari/webkit. Apple heeft de nodige eigenwijze aanpassingen gedaan. Maar dat doet er helemaal niet toe, het gaat om veiligheid, niet om standaarden en een browser als onderdeel van je OS is onveiliger. Dat bewijst Apple hier ook weer even opnieuw. Dit soort zero days kunnen zo hard aankomen op ios omdat je als je voorbij de browser bent, je al heel snel erg diep in iOS zit. Dat is bij andere besturingssystemen al heel lang niet meer zo.

Of Safari wel of niet z'n werk doet heeft daar allemaal niets mee te maken. Dat is een totaal andere discussie.

Maar laten we deze grote ontwerpfout anders even met de mantel der liefde bedekken en lekker naar andere dingen wijzen, dat lost het probleem wel op. Door deze integratie van Apple is iOS nu onveiliger dan Android. Een heel raar idee, dat tot een jaar of twee geleden ondenkbaar zou zijn.

[Reactie gewijzigd door fapkonijntje op 27 juli 2024 09:41]

[R4gnax]

Belangrijk detail: internet explorer was (en is) een ontzettend slecht product, wat geen enkel respect had voor internet standaarden. Dat geldt niet voor Safari/WebKit.

Dat geldt net zo goed voor Safari/Webkit, wat het stokje overgenomen heeft van IE in de categoriën 'meest ver achterlopend'; 'gemiddeld slechtste performance'; 'bugs in implementaties van standaarden'; 'niet-gestandardiseerede eigen toevoegingen die vendor-lockin creeëren'; en 'bewust frustreren van het standardisatie-proces.'

Vooral dat laatste is bij Apple een dingetje. Binnen de gevestigde standardisatie-processen heeft de Apple-vertegenwoordiging er nogal een handje van om zich afzijdig te houden van alle discussie over vorming van een standaard om enkel op het laatste moment niet-constructief te melden dat ze weigeren om de standaard te gaan implementeren, met de nodige regelmaat zonder daadwerkelijke argumentatie; zonder gehoor te geven aan verzoeken om verduidelijking en zonder verdere wil om te onderhandelen over concessies of verbeterpunten voor het wel accepteren en overgaan tot implementatie.

Het elitaire ivoren toren principe strekt ver bij Apple.


Een bekend voorbeeld daarvan is bijv. het proces omtrent het standardiseren van pointer events; een alternatief event model wat alle pointer-based devices - muis; touchscreen; etc. - unificeert en waar developers al jaren naar snakten. Stond uiteraard haaks op Apple's destijds proprietaire en niet gestandardiseerde model voor enkel touch events. Apple weigerde bot de pointer events specificatie te implementeren omdat ze hun eigen touch events al hadden, en dat zou afdoende moeten zijn.

Geloof zelfs dat er ergens in die shit-storm nog eens een commentaar over de tafel gegaan is waarin vrij letterlijk gezegd werd dat Apple's proprietaire touch events afdoende waren om ontwikkelaars complexe interacties voor iOS web-applicaties te schrijven en dat Apple verder niet geinteresseerd was in hoe problemen voor andere platformen dan opgelost zouden moeten worden.


Even ter verduidelijking: zowel touch events als pointer events zijn later gestandardiseerd. De gestandardiseerde touch events zijn echter niet gebaseerd op Apple's specificatie maar primair gebaseerd op de implementatie die Google in Android Chrome gestoken heeft. Deze is sterk geinspireerd op Apple's originele manke model, maar regelt een aantal zaken wel beter en meer consistent en vult een aantal missende features aan die ook binnen de pointer event specificatie bestaan. Apple heeft dit verbeterde model later met terugwerkende kracht grotendeels over genomen, maar er is vziw in complexe edge cases nog steeds geen 100% parity ... want Apple is Apple, uiteraard.

[Reactie gewijzigd door R4gnax op 27 juli 2024 09:41]

[TheVivaldi]

Op Android wel, maar op Chrome OS dan weer niet.

[Zezura]

of je moet willen dat elke app een eigen browser versie gaat inbakken. allemaal dubbele code.
Geen idee of die wel netjes beveiligingsupdates krijgen.

Het in het OS inbakken heeft nadelen, maar veel meer voordelen.

[fapkonijntje]

Wat is dat nou voor onzin? Op Android gebruikt iedere app ook gewoon webview en die webview app is gewoon een onderdeel dat via de play store gaat sinds Android 5. Precies om het probleem dat Apple heeft te voorkomen. Dat kan Apple ook gewoon doen. Geen apps op Android bakken een eigen browserversie in, ze gebruiken allemaal webview. Hoe kom je bij het rare idee dat apps een eigen browser(versie) mee moeten leveren? Apple heeft een domme en onnodige ontwerpfout gemaakt. Dat is ook een van de redenen dat een iOS exploit nog steeds minder oplevert dan een Android exploit. Op iOS is het door dit soort ontwerpproblemen makkelijker geworden.

[Reactie gewijzigd door fapkonijntje op 27 juli 2024 09:41]

[lenwar]

De browsers op Android kunnen gewoon hun renderengine gebruiken als de ontwikkelaars dit willen. Firefox gebruikt bijvoorbeeld hun eigen engine. (Gecko)

Niet-browser apps die kunnen webview gebruiken zodat de ontwikkelaars niet zelf een renderengine hoeven mee te leveren als ze html willen laten zien, maar ze mogen het wel als ze dat perse willen. (Het voegt waarschijnlijk niet zoveel toe voor de meeste apps) Ditzelfde zie je ook in desktop OSen gebeuren. Onder Windows kan een willekeurige applicatie de renderengines van Windows gebruiken, maar ze mogen ook zelf wat gebruiken.

Op iOS mag een app zelf überhaupt geen alternatieve engines gebruiken. Alleen de engines die door Apple worden geleverd. Dit zorgt er effectief voor dat apps bijvoorbeeld geen externe plug-ins kunnen opstarten/gebruiken.

Dit zorgde er in het verleden voor dat Flash niet mogelijk was (wel via een een of andere webservice dacht ik, maar dan werd het niet langer op je telefoon verwerkt. Alleen weergegeven.).

Voor Java geldt hetzelfde.

Op Android kan dit wel allemaal.

[fapkonijntje]

Het grote probleem is dat als je door Safari heen komt met een exploit je wel heel diep in het OS terecht komt. iMessage kent het zelfde probleem. Bij Android zit je als je door gecko heenkomt of door webview nog steeds in een sandbox. Een van de grote veiligheidsproblemen van Windows was vroeger ook precies dit. Exploit in de browser was gelijk raak in het OS.

Of vrije keuze een risico is, ligt aan de architectuur die het mogelijk maakt. In dit geval is het zo dat de Android aanpak sinds Android 5 veiliger uit heeft gepakt, op dit vlak, dan de iOS keuze en dat de iOS keuze bij ontwikkelaars enzovoorts al meer dan 20 jaar voor alarmbellen zou moeten zorgen, juist door het internet Explorer debacle. Maar Apple wijkt niet, ze houden het lekker zo. Lekker doen alsof ze veilig zijn.

[Reactie gewijzigd door fapkonijntje op 27 juli 2024 09:41]

[Mopperman]

Vergeet even niet erbij te melden dan dat WebView ook zo zijn problemen kent, met de auto update uit de play store - zo als deze week nog te zien was:
nieuws: Google bevestigt dat Android-apps crashen door probleem System WebView

[fapkonijntje]

Dat staat helemaal los van of het veilig is of niet. Safari kent ook z'n bugs en een bug in safari oplossen vereist altijd een OS update. Hier heeft Google binnen een paar uur een fix kunnen releasen. Het probleem had ook helemaal niets met de architectuur te maken.

Je kunt er zaken bijhalen die hier niets mee te maken hebben om te doen alsof het allemaal wel meevalt, feit blijft staan dat Apple hier al heel lang een groot beveiligingsprobleem laat bestaan in iOS en daar niets aan doet.

Bugs in de software hebben ze allemaal. Het grote verschil is dat de impact qua veiligheid hij Android veel kleiner is dan bij iOS en dat Google altijd snel een fix kan releasen zonder aan het OS te zitten. Zodoende krijgen alle Android versies na 5.0 direct een patch als er iets in webkit fout gaat. Dat is hij Safari wel even anders.

Hoe kom je er eigenlijk bij om een bug in een app te linken met de architectuur van een OS? Dat staat helemaal los van elkaar.

[Reactie gewijzigd door fapkonijntje op 27 juli 2024 09:41]

[TheVivaldi]

Vergeet even niet dat WebView geen volledige browser is, zoals Safari. Google Chrome is het Android-equivalent van Safari.

[ikweethetbeter]

Ik wacht al even op iOS 15...

[Player86]

Top van Apple dat het snel opgelost wordt.

[kodak]

Het beveiligingslek lijkt al begin december vorig jaar ontdekt te zijn. We zijn nu bijna 4 maanden verder. Daar komt nog bij dat Apple stelt dat het al misbruikt zou worden. Dat wil dus zeggen in de afgelopen 4 maanden of zelfs al eerder. Ik denk niet dat je dan makkelijk kan stellen dat het snel opgelost is. Al is de vraag wel sinds wanneer Apple er zelf genoeg over wist, omdat ze het kennelijk niet zelf ontdekt hebben maar afhankelijk waren van Google.

[K-aroq]

Hoeveel tijd heeft het dan gekost om een oplossing te vinden en dat te implementeren, testen en gereed te maken voor grootschalige roll out? Je kunt wel dingen sneller willen doen maar dat moet ook wel kunnen. Domweg maar meer mensen er op zetten is ook geen garantie dat dingen sneller kunnen.

Maar goed, de Tweakerforummers kunnen dat natuurlijk wel allemaal heel snel.

[kodak]

Daarom stel ik ook dat het de vraag is wanneer Apple er genoeg over wist. Maar gewoonlijk zijn er bij dit soort bekendmakingen hoe lang ontwikkelaars er over mogen doen om het op te lossen. Dat is als ze bij Google een probleem in software van een ander ontdekken 90 dagen, maar als het ook nog een zero-day is die criminelen al misbruiken dan is dat dus niet zomaar snel te noemen.

[TheVivaldi]

Ik hoor juist altijd op Tweakers dat het testen bij Apple heel snel gaat omdat ze maar weinig apparaten hoeven te testen, i.t.t. de (bij wijze van spreke) miljoenen verschillende Android-apparaten.

[Player86]

The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

Het is gewoon een ID nr wat al gereserveerd was voor een nog onbekende kwetsbaarheid.

[kodak]

The record creation date may reflect when the CVE ID was allocated

.
Alloceren wil zeggen alvast beschikbaar maken voor het geval er iemand een beveiligingslek heeft gevonden. Maar er staat ook dat het mogelijk om reserveren gaat, dat is wanneer onderzoekers een beveiligingslek er een CVE ID voor aanvragen, terwijl ze al langer van het beveiligingslek weten.

Daarom stel ik ook dat het de vraag is wanneer Apple er genoeg over wist.

[Orama]

Waar haal je vandaan, dat het snel is opgelost?

[berchtold]

zero-day

[DeFeCt]

En wanneer is hij ontdekt?

[mjl]

Misschien al veel langer geleden dan dat Apple er van wist, criminele hackers willen dat natuurlijk zo lang mogelijk geheim houden om zo veel mogelijk geld er uit te halen.

[MrKaplan]

Wat denk je van overheden?

[mjl]

Sommige overheden zijn toch crimineel

[Tweak3D]

als je wacht duurt het nog langer

[WimV48]

Als je niet wacht duurt het net zo lang, als het duurt.