Apple dicht drie zerodays in iOS

Apple heeft een update voor iOS uitgebracht waarmee drie zerodays worden gedicht. De gaten in de kernel en in WebKit werden volgens het bedrijf actief uitgebuit. Details over die specifieke aanval geeft het bedrijf niet.

Het gaat om gaten in iOS 14.3 en iPadOS 14.3 die zijn bijgewerkt naar versie 14.4. In het besturingssysteem zaten drie bugs, schrijft Apple in de patch notes. De bugs werden aangedragen door anonieme beveiligingsonderzoekers. Een van de lekken zit in de iOS-kernel. CVE-2021-1782 is een privilege escalation-bug die ontstond door een race condition en die kon worden ingeladen door een geïnfecteerde applicatie

Daarnaast zijn ook twee andere lekken ontdekt in WebKit. Daar maakt onder andere de Safari-browser gebruik van. CVE-2021-1870 en CVE-2021-1871 zijn logic issues die waren uit te buiten door een geïnfecteerde website te bezoeken. Daardoor kon code worden uitgevoerd op het apparaat. Apple geeft geen nadere details over de kwetsbaarheden of de aanvallen waarin die gebruikt zouden worden. Gezien de aard van de lekken is het mogelijk dat die in combinatie met elkaar worden uitgevoerd.

Reacties (89)

"Een van de lekken zit in de iOS-kernel. CVE-2021-1782 is een privilege escalation-bug die ontstond door een race condition en die kon worden ingeladen door een geïnfecteerde applicatie"

OK. Nu even 'gewoon' Nederlands en begrijpelijke taal; escalation-bug...race condition WTH!?

Btw, zelf zit ik inmiddels sinds gisteravond al op 14.4. Dus deze issues/bugs heb ik niet meer (gelukkig)

Over wat een race condition is (de heel eenvoudige versie):

De code van een programma wordt meestal in meerdere threads uitgevoerd. Vergelijk het met een weg. Bij een eenbaansweg moeten alle auto’s achter elkaar rijden. Bij een tweebaansweg kunnen auto’s naast elkaar rijden. Zo is het ook met de code van een programma.

Als de code van een programma in 1 thread zou worden uitgevoerd, dan zou bijvoorbeeld een app op je telefoon niet meer reageren als er data wordt gedownload, want dan wordt de netwerk code uitgevoerd en niet de code voor de user interface. Door de code in meerdere threads uit te voeren kan het programma eigenlijk multi tasken.

Maar code is met elkaar verweven en kan elkaar beinvloeden. Bijvoorbeeld (in tijd van boven naar beneden):

• Thread 1. Variabele A = 1
• Thread 2. Variabele A = 2
• Thread 3. Variabele B = A + 3

In dit voorbeeld is B gelijk aan 5 (want A is 2 bij de optelling).

Maar wat als er door wat voor reden ook een vertraging zit in thread 1, waardoor de stap in thread 2 eerder wordt uitgevoerd. Dan is diezelfde code opeens:

• Thread 2. Variabele A = 2
• Thread 1. Variabele A = 1
• Thread 3. Variabele B = A + 3

Nu is B opeens gelijk aan 4, terwijl het eerst nog 5 was. Dat kan een probleem geven als de veronderstelling was dat B altijd 5 zal zijn.

[Reactie gewijzigd door Takezo op 27 januari 2021 09:20]

mooi uitgelegd en mooi voorbeeld ook! top!

Een simpel voorbeeld idd, en in jouw voorbeeld zit eigenlijk geen probleem. Want ook al zou je locking/semaforen gebruiken om toegang tot variabele A te beperken, dan blijft het probleem bestaan en blijkbaar een wens dat het zo werkt.
Het probleem waar ze op doelen is volgens mij “mutually exclusive”; oftewel de toegang tot variabele A moet voor een bepaalde thread tijdelijk exclusief zijn(en dat met een reden omdat de wijziging van A..of beter de State van het object..een complexere wijziging behelst dan A=2) . Oftewel er moet een wachtrij gecreëerd worden van threads die om de beurt variabele A en/of State vh object mogen aanpassen.

Een priv escalatie is een escalatie in rechten, bijv als je als aanvaller op een normale gebruiker terecht komt dan kan je een priv escalatie gebruiken om naar administrator, system of root user te komen.

Ik heb geen flauw idee wat een race conditie is, ik had nog meer vragen toen ik de wiki pagina daar over las.

Een race condition is kort gezegd wanneer er meerdere acties worden uitgevoerd en de uitkomst daarvan niet vast staat omdat die afhankelijk is van timing (beïnvloed door externe factoren). Neem bijvoorbeeld twee threads waarbij soms de ene eerder klaar is dan de andere, door de automatische toewijzing van CPU-tijd, of I/O die wisselend presteert.

[Reactie gewijzigd door Z-Dragon op 27 januari 2021 09:13]

https://en.wikipedia.org/wiki/Race_condition

A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.

The term race condition was already in use by 1954, for example in David A. Huffman's doctoral thesis "The synthesis of sequential switching circuits".[1]

Race conditions can occur especially in logic circuits, multithreaded, or distributed software programs.
--
A race condition arises in software when a computer program, to operate properly, depends on the sequence or timing of the program's processes or threads. Critical race conditions cause invalid execution and software bugs. Critical race conditions often happen when the processes or threads depend on some shared state. Operations upon shared states are done in critical sections that must be mutually exclusive. Failure to obey this rule can corrupt the shared state.

A data race is a type of race condition. Data races are important parts of various formal memory models. The memory model defined in the C11 and C++11 standards specify that a C or C++ program containing a data race has undefined behavior.[3][4]

A race condition can be difficult to reproduce and debug because the end result is nondeterministic and depends on the relative timing between interfering threads. Problems of this nature can therefore disappear when running in debug mode, adding extra logging, or attaching a debugger. Bugs that disappear like this during debugging attempts are often referred to as a "Heisenbug". It is therefore better to avoid race conditions by careful software design.

Kortweg, 2 threads tegelijk actief proberen eenzelfde variabele te bewerken.

Daarom moet je dat dus altijd voorkomen...

Door een aaneenschakeling van issues kan je verhoogde rechten krijgen.

[Reactie gewijzigd door xxs op 27 januari 2021 08:31]

Gaat om een rechten-escalatie. Dat houdt in dat een app meer of hogere rechten kon krijgen middels een escalatie dan toegestaan was.

.. door te hard te rijden

Is humor hier inmiddels ook verboden?
Het downmodden neemt op Tweakers inmiddels onnavolgbare vormen aan.

dat is al jaren - mogelijk meer dan een decennium - een regel. het is off-topic. mogelijk een troll. ergo een downmod.

Yep daar reageerde ik inderdaad op, omdat Jism daar niets over had gezegd met als hint voor iemand om het wel uit te leggen. Dacht dat iedereen hem wel zou vatten haha, helaas!

[Reactie gewijzigd door jkommeren op 27 januari 2021 11:48]

Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user. The result is that an application with more privileges than intended by the application developer or system administrator can perform unauthorized actions.

A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.

Bij Apple is altijd een full updat nodig. Dat duurt een half uur ofzo op mijn xs omdat er een reboot nodig is. Zouden ze niet security updates los kunnen pushen?

Dit is de reden waarom het zo handig is dat je het 's nachts kan doen.

Als ze in de kernel zitten, zoals deze, moet je sowieso rebooten.

Dat is op Windows, Android en gewoon Linux ook zo. Voor Linux zijn wel wat dingen beschikbaar om te hotpatchen zoals canonical-livepatch, maar normaal gesproken zal je gewoon moeten rebooten.

[Reactie gewijzigd door Plofkotje op 27 januari 2021 08:44]

Maar er zit een groot verschil in hoe patches worden toegepast. In geval van Linux is het al jaren zo dat je je systeem gewoon kan blijven gebruiken terwijl patches worden geïnstalleerd. Je merkt daar eigenlijk niets van. Alle services worden automatisch herstart wanneer dat nodig zou zijn, applicaties blijven gewoon werken. Zelfs als die applicatie zelf gepatched wordt. Een reboot is zelden noodzakelijk en er wordt ondertussen al enige jaren gewerkt aan de mogelijkheid om zelfs de kernel te patchen zonder dat een reboot nodig is.

Windows update is ook al jaren aan het beteren in dat opzicht. Reboots zijn al minder vaak noodzakelijk en als ze dat toch zijn, gebeuren ze sneller. Ik heb enkel nog bij de halfjaarlijkse feature updates dat ik lang moet wachten op de reboot.

En dan heb je Apple. Telkens als ik iTunes op Windows update wordt heel de applicatie vervangen, zelfs al is het maar een kleine update. Als Apple zo ook werkt op zijn eigen eco systeem dan vraag ik me echt af waarom ze niet gewoon enkel die dingen updaten die noodzakelijk zijn ipv telkens alles te vervangen. Het scheelt bandbreedte, het scheelt tijd.

En toch moet je in Linux gewoon rebooten bij een kernel vulnerability. Ik ben het met je eens dat de patch anders uitgerold wordt, maar als hij niet te livepatchen is zul je alsnog gewoon de hele server/desktop moeten rebooten.

Klopt maar een full system update voor een browser patch...

Dit was een kernel patch + webkit patch.

Ja, dus de webkit patch gaat ook via de system update. Wat @bartje vraagt is of ze de securty niet los kunnen patchen. Het antwoord was dat kernel zaken altijd een reboot nodig hebben, maar daar valt de webkit niet onder, dus inderdaad waarom kan die niet los geupdate worden? Dat het nu samen gebeurd is niet echt een argument om het samen te laten gebeuren...

Heb net een 12 ge-update en die doet er 15 minuten over waarvan je hooguit 5 minuten geen bruikbaar toestel hebt. (grootste deel van de upgrade tijd van iOS is het snapshotten van de interne opslag zodat je telefoon geen baksteen wordt als de upgrade halverwege faalt)

Dat is ook nog altijd mijn wens, dat Apple z'n eigen apps ook gaat zien als losse, te updaten, apps en niet als deel van het OS. Helaas zijn echter een hoop zaken die in de eigen apps zitten, ook diep verbonden met het OS en worden delen ervan door andere apps (al dan niet noodgedwongen) gebruikt. Denk aan het webkit deel van Safari, dat ook door andere apps moet worden gebruikt en dus zich op OS niveau bevindt.

Maar het zou dus fijn zijn als bv Music of Podcasts of Weather ook losse updates zou krijgen tussendoor, ipv wijzigingen ten tijde van een grote OS update.

Naja... eens in de grofweg 2-3 maanden je telefoon een half uurtje niet gebruiken kan ook een 'opluchting' zijn. Toch?
En daarbij... je kunt toch ook aangeven dat je 's nachts wilt updaten als je ligt te slapen. Of in ieder geval op een tijdstip de update uitvoeren wanneer jij wilt (tijdens eten, rondje rennen, hond uitlaten, eten koken, weer even levellen in c-tijden met je partner of bijpraten met je ouders/goede vriend(in) - via een andere telefoon, dat dan weer wel - of met/bij een andere hobby)

Ik begrijp je punt: sommige updates zijn relatief 'klein' en behoeven geen full-update c.q. reboot. Maar ja...,zo is iOS opgebouwd dus heb je er maar mee te "dealen" (of een change-request bij Apple indienen voor een dergelijke functionele wijziging)

Daarbij is je telefoon heb half uur onbruikbaar, het meeste van de tijd zit in voorbereiden als je iPhone nog te gebruiken is.
De herstart duurt misschien 10/15 min dat even niet te gebruiken is, dus zolang is dat ook weer niet.

Bij mijn Android toestellen krijg je ook gewoon elke keer zo'n huge download voor je kiezen + een reboot cadeau, dus wat dat betreft is het allemaal een pot nat.

Bij Apple is altijd een full updat nodig. Dat duurt een half uur ofzo op mijn xs omdat er een reboot nodig is. Zouden ze niet security updates los kunnen pushen?

dat kan wel, ook iOS updates zijn delta's, je hoeft niet het hele ding binnen te leuren over the air.

Bij Apple is altijd een full updat nodig. Dat duurt een half uur ofzo op mijn xs

Ik begrijp dat wellicht anders (ik ben een leek in programmeertaal), want mijn Xs Max ging dus nu van 14.3 naar 14.4 en dat was een dikke 300MB. Het herstarten zelf waarbij de telefoon onbruikbaar was (lees: het Appeltje met die balk onder) heeft geen tien minuten geduurd.
Als er in het verleden van iOS 13 en zoveel naar 14 gegaan werd spraken we over ettelijke GB's. Herstart duurde uiteraard ook langer.

Dan worden er in het geval van ios 14.3 naar 14.4 toch maar enkele onderdelen geupdate, of ben ik daar mis in?

Weer een mythe debunked dat IOS veiliger is dan Android.

Hoe kom je daarbij? Kan je dat onderbouwen?

Lees gewoon het nieuws en de enorme hoeveelheid bugs en flaws IOS heeft. Er wordt veel en veel vaker melding gemaakt van weer een kwetsbaarheid in IOS dan in Android. Kwestie van een breed aanbod van goede bronnen raadplegen.

https://www.youtube.com/watch?v=Nug0KlQ9kVk
https://onezero.medium.co...an-ios-4a2ca6f359d3?gi=sd
https://www.notebookcheck...han-iPhones.452553.0.html
https://www.cultofmac.com...-actually-safer-than-ios/

https://bit.ly/3iYoesI

[Reactie gewijzigd door NietVerplicht op 27 januari 2021 13:24]

Oh oke, ik wist niet dat iOS eerst veiliger was dan Android. Voor mij zijn het allemaal iot apparaten, stuk voor stuk gevoelig voor bugs, vulnerabilitys en hackers. Met andere woorden: Geeneen iot apparaat is veiliger dan het andere, slechts afhankelijk van hoeveel (al dan niet slechtwillende) hackers zich ermee bezig houden en hoe bekwaam deze zijn in hun vak.

[Reactie gewijzigd door Generaal Pep op 27 januari 2021 13:47]

Dat is best wel serieus, 3 zero days die actief misbruikt worden.

Is dit niet veel t.o.v. b.v. Android of Windows?

Nee volgens mij is dit niet heel bijzonder t.o.v. Windows/Android. Het komt vaker voor dat aanvallers een serie van lekken gebruiken om ergens binnen te komen. Alhoewel dit natuurlijk lastig te zeggen is om dat zero-days uiteraard niet bekend zijn bij de makers van software. In de tienduizenden regels aan code waarom een OS bestaat moeten statistisch gezien ook wel bugs en security issues zitten.

Overigens is met de toenemende populariteit van Apple devices het aantal zero-days ook best wel hard toegenomen. Ik heb even geen bron, maar had ergens gehoord dat de prijs voor een iOS zero-day op de zwarte markt best wel hard is gedaald. Puur omdat er meer hackers actief opzoek zijn en dus ook meer vinden.

Met de toenemende populariteit van Apple devices? Juist het marktaandeel is al een aantal jaar heel stabiel. Zowel iOS apparaten als macbooks/macs groeien al een tijdje niet meer en dat is ook de reden dat Apple zo vol inzet op diensten. De rek is er uit qua marktaandeel. De winst bij Apple is wel gestegen, maar dat komt vooral door meer bezuinigingen en hogere marges, samen met een algeheel groeiende PC markt. Apple is dus wel meer gaan verkopen, maar niet meer dan de markt zelf groeide. Er zijn wat gokjes geweest rond oktober die deden alsof Apple groeide, maar die zijn gebaseerd op omzetcijfers en niet afzetcijfers (want die geeft Apple niet). Apple doet nu wel een poging met het capabeler maken van een serie als een Macbook Air, om zo te kijken of ze nog marktaandeel kunnen winnen. Dat kan voor consumenten heel interessant zijn. Het jammere is wel dat de hardwarekwaliteit flink heeft ingeboet de laatste paar jaar en dat Apple daar heel traag op reageerde (hallo butterfly toetsenbord).

De prijs van een iOS zero day is gedaald omdat ze makkelijker te vinden zijn en alternatieven (Android) de laatste paar jaar héél hard bezig zijn geweest met het verbeteren van de veiligheid. Dat maakt het makkelijker (en dus goedkoper) om een iOS vulnerability te vinden/kopen. Dat iOS by design veiliger is dan Android is ook achterhaald en Apple heeft de nodige missers gemaakt de laatste paar jaar. Vooral op het gebied van testen.

[Reactie gewijzigd door fapkonijntje op 27 januari 2021 09:46]

Marktaandeel in aantallen (wereldwijd) Q4 2020 is ongeveer 31% hoger dan Q4 2019 en 22% hoger 2020 vs 2019:
https://www.macrumors.com...ments-up-4q-2020-gartner/
En dit in een groeiende markt. Apple doet het dus niet slecht.

Je tabelletje; Gartner's Preliminary Worldwide PC Vendor Unit Shipment Estimates for 4Q20 (Thousands of Units)

Zo zijn er van andere bronnen ook gokjes gedaan. Apple geeft geen afzetcijfers. Het zijn allemaal gokjes op basis van de omzet van Apple en niet de daadwerkelijke verkochte units. Dat maakt dit soort verhalen een beetje misleidend. Natuurlijk gaat een fansite als macrumors daar vol in mee. Dat snap ik.

Kijk je naar de marktaandeel cijfers (ook de geschatte, bijvoorbeeld die van IDC in jouw artikel), dan zie je dat schattingen maar een paar procent meer of minder geven dan voorheen. Allemaal een percentage waar Apple al bijna 10 jaar omheen schommelt. Het is vrij logisch dat de omzet groeit als de totale markt groeit en je marktaandeel stabiel blijft. Dan verkoop je meer, maar de concurrentie óók.

[Reactie gewijzigd door fapkonijntje op 27 januari 2021 13:36]

Heb jij dan wel getallen voor de concurrenten?
Nee dus, want deze zijn ook allemaal schattingen van IDC of Gartner.

En andersom: Deze schattingen worden opeens wel geloofd om te laten zien dat het marktaandeel van Android smartphone leveranciers zoals Samsung hoger is dan Apple’s iPhone marktaandeel.
Waarom moeten we deze dan opeens wel geloven?
Dat terwijl Samsung zelf geen cijfers geeft en zelfs wijst naar IDC en Gartner. Toch apart, niet? Je zou verwachten dat Samsung ofwel dit zelf kan melden, ofwel domweg niets zegt.

Dit is redelijk veel zo in een keer, maar dat komt bij Windows en Android ook soms voor. Qua kwetsbaarheden die gevonden worden is iOS in totaal erg gemiddeld.

Tja.

Een bedrijf dat veel bugs fixt kan:

A. Heel goed bezig zijn met security en actief bugs opsporen en oplossen.

B. Heel veel bugs hebben.

Maar, bugs/exploits zijn er altijd, als een bedrijf ze actief fixt, is dat sowieso goed.

Wij fixen vooral 'yesterdays' i.p.v. 'zero days'. Management geeft namelijk aan dat al die features gisteren al af hadden moeten zijn (:

Wij fixen vooral 'yesterdays' i.p.v. 'zero days'. Management geeft namelijk aan dat al die features gisteren al af hadden moeten zijn (:

Dus de hoogste tijd om je tijd aan een beter bedrijf te gaan besteden lijkt me.

Nee niet echt. Een patchdindsdag bij MS kan soms wel tientallen zero days fixen.

Volgens mij heb ik nog nooit meer dan 3 zerodays tegelijk in een Patch Tuesday gezien. Tientallen lijkt me erg overdreven...

Even als voorbeeld In november 2020 17 stuks:
https://msrc.microsoft.com/update-guide/releaseNote/2020-Nov

Ik wil niet twijfelen aan je woorden maar waar kan je zien dat dit zerodays zijn?

Dat zijn toch geen zerodays? 17 leaks met een 'critical' rating, maar geen actief uitgebuite lekken.

5 tegelijkertijd: https://www.netsec.news/5...days-fixed-patch-tuesday/

Met de kanttekening dat een aantal van die zero days in verschillende software zitten (zoals Office) die geen onderdeel zijn van het OS. Dus in Windows is het helemaal geen 5 tegelijk. Patch Tuesday patcht zo'n beetje alle MS software, beetje misleidend dus om alles op één hoop te gooien. Tel in een week maar op wat macOS, iOS en andere software van Apple voor fixes krijgt, dan kom je ook wel boven de 5 zero days uit in sommige weken.

Inderdaad, en 5 is geen 10. Maar ook wat wel gevonden opgelost wordt zegt niets over de niet gevonden zerodays die misschien wel door criminelen/geheime diensten uitgebuit worden - wat het vergelijken lastig maakt. En de vraag; Safari: OS of add on? want 2 van de 3 zerodays gaan over safari.

Dit artikel is al 12 jaar oud, wie weet hoe de zaken nu staan...

https://www.computerworld...es-zero-days-faster-.html

ah, gevonden: android lijkt veiliger nu:

https://onezero.medium.co...fer-than-ios-4a2ca6f359d3

[Reactie gewijzigd door Shark.Bait op 27 januari 2021 16:01]

Safari zit ingebakken in het OS en kan alleen een update krijgen bij een iOS update. Ontwerpfout die MS honderd jaar geleden ook maakte met Internet Explorer en nu ongedaan probeert te maken. Apple doet dat gewoon dunnetjes over met iOS en Safari.

Safari zit ingebakken in het OS en kan alleen een update krijgen bij een iOS update. Ontwerpfout die MS honderd jaar geleden ook maakte met Internet Explorer en nu ongedaan probeert te maken. Apple doet dat gewoon dunnetjes over met iOS en Safari.

Safari komt inderdaad alleen met een OS update mee, maar volgens mij zit het niet volledig geïntegreerd / deep verweven in het OS zoals MS ooit deed met IE. Het is gewoon een sandboxed applicatie.

[Reactie gewijzigd door arjankoole op 27 januari 2021 18:24]

Het kan niet helemaal handboxed zijn aangezien veel apps verdedelde websites zijn

Wat ze hopelijk anders doen t.o.v. Microsoft zoveel jaar geleden is het renderen van OS onderdelen met de webengine

Apps die veredelde websites zijn, gebruiken de Safari API. Draait nog altijd sandboxed. (in dat geval de zandbak van de app)

Dat is precies dezelfde situatie als bij windows... als je integratie wilt vergelijken moet je dus een laag dieper gaan

Dan is de vraag meer... gebruikt IOS de apis van safari of is het andersom

Thx iedereen.

Klinkt inderdaad heftig. Even ook mijn omgeving aangeven te updaten naar 14.4 dan

Ik vind het ook jammer dat er geen Security patches zijn voor oudere IOS versies of telefoons. Dus een iOS 9 net maar geupdate naar de laatste versie, maar daar wordt de telefoon vast niet sneller van (6s).

De iPhone 6S wordt gewoon ondersteund door iOS14. Dus ik snap niet waarom je (afgezien van performance) niet zou upgraden naar de meest recente, stabiele en veilige versie. Je loopt met die oudere versie namelijk ook allerlei risico's. Een verstandig mens blijft ook geen gebruik maken van internet via Windows XP.

Ik ben verre van een Apple fan, maar ik moet toegeven dat ze hun support en ondersteuning voor oudere toestellen (iPhone 6S is uitgebracht in september 2015) gewoon goed voor elkaar hebben.

Ja klopt, het is een telefoon die door de kinderen wordt gebruikt, zonder bankieren of email apps. Het punt is juist die traagheid. bij deze iOS moet ik het nog zien hoor, maar ervaringen uit het verleden leren me dat na een aantal updates de toestellen zo traag worden dat er niet meer mee te werken is.

Vandaar, als ze nou security updates zouden aanbieden op de iOS versie, zonder volledige upgrade, zou dat wel fraai zijn.

Ze geven Security updates als iOS ondersteuning afloopt, Apple heeft voor ios12 nog
Genoeg Security updates gegeven afgelopen 1,5 jaar.

Aangezien alle devices die ios13 hadden nog 14 ondersteunen, zal er voor ios13 geen Security updates komen.

Je toestel wordt nu nog ondersteund, dus krijg je zowel Security als nieuwe functies.
Uiteindelijk is ook goed om versie upgrades te krijgen, zat apps die ondersteuning van bepaalde versie uiteindelijk laten vallen(met Android zelfde).

De 6s zal net als de oude Se dit jaar afvallen, en geen ios15 meer krijgen.
Dan krijg je dus wellicht nog tijdje Security updates alleen, net zoals met ios12 ook gebeurt voor de 5s en 6.

[Reactie gewijzigd door Carlos0_0 op 27 januari 2021 12:27]

We hebben nog een 6S Plus en die gaat best prima op iOS 14. Niet zoals een iPhone 12 misschien, maar goed: we hebben het over een telefoon uit 2015. Leg een MacBook Air uit 2015 naast een MacBook Air uit 2021 en het verschil is groter.

[Reactie gewijzigd door BikkelZ op 27 januari 2021 10:18]

We gaan het straks zien :-).

De upgrade ging goed, en de snelheid is nog ok :-)

Ja iOS 12 was een sterke verbetering van de snelheid met de versies er voor, 13 een regressie en 14 weer iets beter. Dus hij is weliswaar langzamer dan iOS 9 en 10 maar sneller dan 11 en 13.

Ik vind het ook jammer dat er geen Security patches zijn voor oudere IOS versies of telefoons. Dus een iOS 9 net maar geupdate naar de laatste versie, maar daar wordt de telefoon vast niet sneller van (6s).

het is niet gezegd dat die überhaupt dat lek hebben. Bij mij krijgen devices die niet meer geüpdate kunnen worden naar de meest recente versies (op moment van schrijven 1 apple watch gen 2 en 1 iPad mini 2) nog altijd security updates.

Is de timing van dit nieuws vanuit Apple wel handig? Sinds ca een week heb ik via automatische updates 14.3 en nu moet ik actief vragen om de update naar 14.4. Het lijkt me handiger om eerst 14.4 te pushen en dan pas het nieuws uit te brengen, of wordt dit nu al volop misbruikt?

Volgens Apple zelf worden de exploits mogelijk al volop misbruikt ja:
https://support.apple.com/en-us/HT212146

Dat zou je zeggen, maar ik kan me voorstellen dat dit een andere afweging is.

Het wordt al misbruikt, dus elke dag dat een gebruiker 14.4 niet heeft is een risico voor die gebruiker.
Er zijn altijd mensen die een update die gepusht wordt toch blijven uitstellen. Sommige mensen zitten nog op IOS 12 of 13 tenslotte. Het actief aanbieden helpt niet om iedereen te bewegen te updaten ... en echt verplicht maken kan/doet Apple niet. Er zullen dan altijd berichten in de media verschijnen van mensen die dat niet wilden want nu werkt xyz niet meer.

Ik kan me voorstellen dat er daarom bedacht is om iets meer open kaart te spelen om in ieder geval zoveel mogelijk mensen die anders uitstellen duidelijk te maken dat dit echt een belangrijke update is. De update is ook al meteen vanaf datzelfde moment verkrijgbaar en te installeren. Ze zullen hem heus wel op een sneller tempo uitrollen dan jouw voorbeeld van 14.3 die je pas na 6 weken krijg (begrijp ik uit je tekst).

macOS zal ook volgen binnen een dag of wat: https://twitter.com/schlix_gawd/status/1354313106185449474

(Waarschijnlijk patchen ze de sudoedit bug CVE-2021-3156 ook nog even mee)

[Reactie gewijzigd door Henk Poley op 27 januari 2021 09:20]

Xcode is al gevolgd. Zit nu op 12.4.

[Reactie gewijzigd door Jan-E op 27 januari 2021 14:10]

macOS duurde wat langer, maar Big Sur 11.2 is nu beschikbaar. Ik krijg hem nog niet direct te zien in software update. Dat duurt misschien nog even.

De sudo is daarin niet geupdated.

Zou de privilege escalation-bug (CVE-2021-1782) ongeveer hetzelfde zijn als CVE-2021-3156? Of is dit echt iets anders?

https://www.zdnet.com/art...s-gain-root-level-access/

[Reactie gewijzigd door TwArbo op 27 januari 2021 09:12]

nee, dan zou deze geen eigen CVE krijgen. Die sudo bug is wel van toepassing op MacOS verwacht ik.

Gister kwam deze lek dat sudo een buffer overflow heeft en welke er al 10 jaar in schijnt te zittten. https://blog.qualys.com/v...low-in-sudo-baron-samedit

Het kan zo lijken, maar mijn iPhone 7 Plus lijkt na deze update ineens een stuk sneller te zijn.

Had je hem toevallig al een tijdje niet gereboot?

Neehoor, toevallig eer-gisteren weer eens gedaan na paar weken aan te laten
Viel me op dat bijv. het openen van signal ineens met een lagere framerate ging en het tobo kwam maar traag omhoog.

Zelfde was het geval met de camera-app. Foto gemaakt.. 1 tel, 2 tellen.. ennnnn de foto is nu pas opgeslagen.

Dat was ook de reden van herstart toen.

Is nu ineens allemaal over. Zal misschien toeval zijn.

[Reactie gewijzigd door R_Lee op 27 januari 2021 13:20]