Apple werkt aan patch voor bootloop-bug iOS-apparaten

Apple erkent dat het terugzetten van de datum naar een moment voor mei 1970, ervoor kan zorgen dat iPhones en iPads niet meer opstarten. De fabrikant belooft met een software-update te komen die het probleem verhelpt.

In een korte verklaring bevestigt Apple het probleem dat handmatig terugzetten van de datum naar mei 1970 of eerder ertoe kan leiden dat een iPhone, iPad of iPod Touch niet meer opstart. Een komende software-update voor iOS moet een einde aan het probleem maken. Gebruikers die getroffen zijn, dienen zich tot Apple Support te wenden. Niet bekend is wanneer die update dan moet verschijnen. In maart brengt Apple iOS 9.3 uit maar het kan ook dat het bedrijf besluit tussentijds een update uit te brengen.

De bug kwam vorige week aan het licht en lijkt alleen apparaten met een 64bit-soc te treffen, oftewel de iPhone 5s en nieuwer en de iPad Air en nieuwer. De oorzaak is niet bekend en ook Apple zegt hier niets over. Gespeculeerd werd dat de bug te maken heeft met een Unix-timestamp, die aan 1 januari 1970 middernacht GMT het getal 0 toekent en ten westen van deze tijdzone een 'negatieve tijd' zou aanduiden bij gebruikers die de datum aanpassen. Gebruikers moeten veel moeite doen om de betreffende datum in te stellen maar op internet circuleren al scams om mensen hiertoe te bewegen, onder andere met de belofte dat een easter egg gevonden kan worden.

 

Reacties (96)

Tom Scott heeft weer een mooie duidelijke uitleg over het probleem:
https://www.youtube.com/watch?v=MVI87HzfskQ

Het is wel belachelijk dat dit optreed. Gewoon goed oplossen en geen minor patches.

Weet je hoe moeilijk datum en tijdzones voor programmeurs zijn? Om even je geheugen op te frissen: https://www.youtube.com/watch?v=-5wpm-gesOY

Sorry, totaal offtopic, maar wat een geniaal filmpje!

Heel de Computerphile (en ook Numberphile) serie bestaat uit geniale filmpjes! :-)

dat kan ik geheel offtopic edoch volmondig beamen

Gaat niet over tijdzones maar over het feit dat Unix tijd 0 secs 1-jan-1970 is.
Dat je machine daardoor blijft crashen is natuurlijk wel belachelijk.

reken maar eens de Unix max tijd uit dat wordt het volgende probleem dan, maar ach ja wie dan leeft dan zorgen heeft

Er zijn voldoende andere manieren om dit te doen!!

Uiteindelijk komt het toch weer op tijdzones en datumberekening (verschillende kalenders) neer want ergens wordt blijkbaar de UNIX tijd gebruikt en daarna wordt aan de hand van de tijdzones berekend wat de juiste datum/tijd moet zijn en daarbij lopen ze waarschijnlijk tegen een integer underflow aan (zoals ook vermeld in het filmpje van Computerphile). Dat is ook de reden waarom het ook niet alleen bij 1 januari 1970 gebeurt maar ook bij het (quote van het artikel) "terugzetten van de datum naar mei 1970 of eerder ".

[Reactie gewijzigd door Myrdhin op 17 februari 2016 07:48]

Het is maar hoe je het uit wil leggen, het simpele feit dat tijd 0 minus een tijdzone een system crash geeft is gewoon slecht. Lijkt me niet ingewikkeld om dit af te vangen. In dit geval niet gebeurt.

Als je in C werkt en je hebt de borland c en microsoft c discussie meegemaakt dan begrijp je dat dit geen crash mag geven. (oost vs west kust).

Heb je het artikel wel gelezen? Het kan gebeuren met elke tijdstip vanaf mei 1970 en eerder. Dus het is net zomaar een "0 - tijdzone" probleem en gaat veel dieper dan dat. Het hele tijd/datum gebeuren zijn waarschijnlijk libraries met duizenden regels code. Je kan gewoon simpelweg niet alles testen.

Nu weten ze van deze fout dus waarschijnlijk hebben ze gelijk een testcase ingebouwd in de unittests.

Het is dus wel een 0 probleem, alles wat een datum-tijd heeft en dan daarvan een berekening maakt voor dit punt.

Je kan er lang over een discussie over voeren maar in het jaar 2016 zo'n fout maken is gewoon ERG slecht.

Die integer overflow moeten ze toch kunnen handelen.
Vervelende data is 1 maar een boot loop ???

Je kan niet alles testen, nee dat klopt maar met y2k bug periode is er erg veel tijd aan besteed en je zou zeggen we hebben wat geleerd?

Dit wordt de volgende:
https://en.wikipedia.org/wiki/Year_2038_problem

Specifiek over dit probleem:
https://www.youtube.com/watch?v=MVI87HzfskQ

Dat is niet de eerste post. Kijk naar de tijdstempel. Dit was een reactie op Myrdhin toen de reactie van ToolkiT nog lager in de discussie stond (En ik die uiteraard niet gelezen had).

Je zal gelijk hebben. Excuses. Snap alleen niet hoe de reactie van Toolkit dan opeens bovenaan is komen te staan. Ik zou zeggen, oudste reactie is bovenste reactie, maar zo werkt het blijkbaar niet begrijp ik nu.

De kans is groot dat Apple dit niet 'gewoon goed' kan oplossen, gezien het een breder probleem is dan enkel Apple.

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

Dat de unix timestamp niet verder terug gaat dan een bepaalde tijd is by design en dus geen bug ofso, als ontwikkelaar heb je er dan ook gewoon rekening mee te houden (immers is dat altijd al zo geweest, al 10tallen jaren), iets wat ze bij Apple dus niet hebben gedaan!

Ik kan bij mijn toestel niet verder terug dan 2000 selecteren, dus daar is ook geen probleem

[Reactie gewijzigd door watercoolertje op 15 februari 2016 17:36]

Probleem is ook niet zozeer dat je de iphone op unix-time 0 zet.. dat werkt.. het gaat er om dat er bepaalde software kijkt naar current_time-X om bijvoorbeeld je missed calls van x dagen geleden wil laten zien.. de system date word dan unix-time -X.... en aangezien de systemdate geen signed integer is word dat een getal dat niet klopt..

Beter uitgelegd in:
https://www.youtube.com/watch?v=MVI87HzfskQ

Dat heb je dus alleen als je je tijd te ver terug kan zetten, en dus een iPhone probleem...

Als een iPhone er last van heeft en elke andere telefoon niet, is het dan een breed probleem? Nee helemaal niet, hoe je het ook uit legt wat er mis kan gaan bij het gebruik van een unix timestamp, met de nadruk op kan, waar dus alleen Apple daar niet over na gedacht lijkt te hebben...

[Reactie gewijzigd door watercoolertje op 16 februari 2016 08:56]

Je kan gewoon gebruikers niet de tijd zo ver terug laten zetten. Het is nergens voor nodig dat uberhaupt nog te ondersteunen.

Waarom niet, dit kan ook invloed hebben op andere datum velden die valide voor 1-1-1970 kunnen zijn. Deze datums moet je ook mee kunnen rekenen.

Data die valide voor 1-1-1970 kunnen zijn worden niet als UNIX timestamp opgeslagen.

Jawel hoor, als signed INT waarbij het een negatieve waarde heeft.

Wat bedoel je precies?
Misschien denk je dat een minor patch een quick fix is. Maar dat is niet de definitie van een minor patch. met een minor patch kun je zowel quick fixes als goede oplossingen uitbrengen. Minor geeft meestal alleen aan dat er geen of slechts kleine functionele wijzigingen zijn.
Dit kan dus best met een minor patch gedaan worden.

Waar ik dan weer benieuwd naar ben, hoe krijg je een patch geïnstalleerd op een apparaat dat in een boot-loop zit?

Aansluiten via iTunes? Ik weet niet hoe iTunes werkt, maar vaak kun je zo alsnog dingen naar een toestel pushen.

Je kunt, uit de tijd dat ik nog een iphone had, de tel. In een updatestand zetten door de homeknop tijdens het aanzetten ingedrukt te houden geloof ik. Dan kun je hem idd via itunes updaten. Zulke opties bestaan doorgaans voor elke smartphone.

Als je toestel al in een boot loop zit moet je contact opnemen met Apple support. Wat schijnt te werken is het toestel openen en de batterij loshalen of een week wachten tot de batterij leeg is.

Dit vind ik een goede vraag aangezien je namelijk tijdens die bootloop niet met iTunes kan verbinden
én DFU mode werkt ook niet!

Enige oplossing is hierbij de batterij los laten koppelen. _{Deze grap heeft een vriend van mij 10 euro gekost.}

die aan 1 januari 1970 middernacht GMT het getal 0 toekent en ten westen van deze tijdzone een 'negatieve tijd' zou aanduiden bij gebruikers die de datum aanpassen.

...aangezien wij (Nederland, België) ten oosten van GMT wonen zou het hier dus geen eens een probleem kunnen zijn, toch?

Dan zet je de tijdzone toch gewoon op GMT -1?
Als je problemen zoekt, kun je ze krijgen

[Reactie gewijzigd door GeeBee op 15 februari 2016 17:25]

Dat ligt eraan hoe de tijdzone omgerekend wordt, en dus wat er van je verwacht wordt dat je invoert. Als je ten oosten van GMT een lokale tijd moet invoeren, is in dat geval GMT juist vroeger.

Je leest het dus verkeerdom. Wat de tekst zegt, is dat als de naar GMT omgerekende tijd 0:00:00 is, zou de *weergave* daarvan ten westen van GMT in 1969 liggen. Maar het weergeven van tijd is vgs mij het probleem niet - het probleem is de opslag ervan. Of eigenlijk, hoe de vliegende neuk Apple heeft verzonnen om ermee om te gaan, want either way, het gaat kapot.

Er moet nog wel sneller patches komen want iedereen kan nu slachtoffer worden als iemand je prankt met je telefoon bijvoorbeeld.

[Reactie gewijzigd door RoffaboyS op 15 februari 2016 21:37]

Het is niet zo dat je dit ff snel in stelt ofzo. Je moet namelijk helemaal scrollen naar die datum, iets wat nogal even duurt. Daarbij moet je het in een aantal stappen doen...

Lol wilde ik ook zeggen want er zijn genoeg mensen de geen beveiliging hebben en op school kan je dan ook nog wat doen

Het percentage mensen met een beveiliging is ontzettend hard gegroeid vanaf de iPhone 5S dankzij de vingerafdrukscanner. Vermits de bug zich enkel voordoet op toestellen met 64 bit soc betekend dat dus enkel op toestellen met een vingerafdrukscanner.

Ik gok er op dat Apple binnen enkele dagen een minor update hiervoor uit brengt en dat de datum dan niet verder terug kan dan 2 januari 1970.

Dan denk ik dat je die gok verliest. Als het probleem echt aan de tijdzones ligt, dan los je dat op door daar rekening mee te houden. Maar wij weten niet wat het exacte probleem is. Maar ze zullen zeker met een betere fix komen dan niet kunnen instellen op 1 jan 1970. Dat zou er bij mij niet door heen komen. En ik denk al helemaal niet bij Apple.

Ik zie niet in waarom dat niet een perfecte fix zou zijn (ik zou zelfs wat meer marge nemen): de fix is uiterst eenvoudig te implementeren en te testen en werkt wellicht perfect. Beginnen prutsen aan iets ingewikkeld zoals tijd-zone management zou er bij mij niet doorheen komen...

Alleen is dit een teken dat er iets niet goed zit in hun unix_time code/implementatie wat ik vermoed ze liever gewoon goed fixen in plaats van te komen met 1 of ander halfbakken oplossing.

Dat is geen halfbakken oplossing, het is de enige goede. Het is weinig zinvol om in het tijdszone mgmt code te zetten die checkt op een hardcoded datum/uur - om dan wat te doen als het de bewuste datum betreft????

Wie zegt dat het probleem in de tijzone management zit? Als Apple nu al spreekt van datums voor mei dan zit de kern van het probleem dus niet in het opslaan van de systeemdatum maar loopt het ergens fout in een berekening.

Apple heeft daarnaast al een heel slecht track record als het op tijd gerelateerde bugs aankomt. Ga een oplossing dan niet snel bij elkaar hacken, maar kom aub met een degelijke fix.

Niet moeilijk doen: tijd niet meer op een datum in 1970 laten zetten en die bug is perfect gefixed.

Heeft niets met moeilijk doen te maken. Je lost namelijk het probleem niet op, je laat een potentiële bug zitten die later opnieuw kan opduiken. Je leert niet van de fouten die gemaakt zijn. Dat is een plijster beleid. Je moet problemen altijd zo dicht mogelijk bij de oorzaak aanpakken en niet enkel de symptomen bestreiden. Dat laatste is wat MS jarenlang gedaan heeft en je ziet wat voor een reputatie het hen op gebied van veiligheid heeft opgeleverd.

Ik ben het eens met je principes, maar je diagnose is verkeerd. De oorzaak van de bug is de nultijd. Die bestaat eigenlijk niet, maar door een technische beperking in Unix id praktijk wel. Je moet dus die ongeldige datum gewoon onbereikbaar maken voor de tijdszone routine, die perfect werkt.

De "bug" zit eigenlijk in Unix, maar het lijkt me niet wenselijk die te fixen...

Zoals hierboven aangegeven gaat het hoogstwaarschijnlijk om een opslagveld dat geen negatieve waarden aankan. Gmt-23 is geloof ik de minimale tijdzone, dus gmt 0 wordt in dat geval min, tenzij je een dag later zit. Daarmee dus wel opgelost. Ook is er naar mijn idee geen valide reden om die tijd nog te kunnen gebruiken dus zou ik t een prima oplossing vinden als ze t zo doen.

Omdat er altijd nog een andere situatie kan onstaan in het OS waarbij een/de tijd negatief wordt. Dit soort bugs die het systeem volledig neerhalen en onbruikbaar maken dienen niet gefixed te worden met workarounds.

ik los het liever goed op dan dat ik pleisters plak, want dat is dit. Ik neem aan dat je deze software misschien nog vaker wilt gebruiken, en als je de fix op een andere plek legt, zoals het niet kunnen invoeren van 1 jan 1970, dan blijft de bug in de code zitten, je omzeilt het alleen. Maar dat kan inderdaad een keus zijn.

Envoudige fixes zijn de beste fixes! De bug is dat er bij berekening van tijdszones niet met een limitatie wordt rekening gehouden (de limitatie dat de berekening niet werkt in de buurt van de begintijd). Gewoon de limitatie verwijderen is verreweg het simpelste. Ik begrijp niet dat mensen dit complexer willen maken. Goede software is eenvoudige software!

Eens dat software beter eenvoudig blijft. Maar als je alle bugs op deze manier oplost word de software niet eenvoudig. je weet op een gegeven moment niet meer welke bug bij welke pleister hoort. of dat er meerdere pleisters zijn.
Als iemand die stukken code wilt hergebruiken (want waarom zou je het wiel opnieuw willen uitvinden) en is zich niet bewust van de bug, dan gaat ie daar ook weer tegen aan lopen.

Ik heb code gezien met veel van zulke pleisters, en uiteindelijk kon je de basis niet gebruiken zonder alle pleisters te vinden (want die zitten ergens anders dan waar de fout zit) Nou, daar word je blij van.

Als je code nooit hoeft her te gebruiken of te onderhouden: ja, plak maar pleisters, anders los het probleem bij de oorzaak op. of plak eventueel een pleister en documenteer dan in ieder geval in de buggy code waar die pleister zit.

We zijn het eens over de principes. Maar ik zie in de verste verte niet in waarom dit een pleister zou zijn.

Iets wat de daadwerkelijke bug niet oplost noem ik een pleister.

De "bug" is dat een bepaalde routine (wellicht het timezone mgmt dus) geen rekening houdt met een bepaalde grenswaarde, zijnde de "unix nul-tijd".
Er zijn daarvoor twee mogelijke oplossingen: je zet logica in een complexe functionaliteit, om elke keer te checken of je niet tegen de grenswaarde aanloopt (en wat doe je dan, als je er wel tegenaan loopt?). Of je zorgt gewoon dat je de grenswaarde nooit kan bereiken door een zeer eenvoudig en efficiënte ingreep in de functie waar je de tijd instelt. Ik vind niet dat timezone mgmt zich moet bewust zijn van een "nultijd", dat is de zaken nodeloos complex maken. En "nodeloos complex" is de oorzaak van héél veel bugs.

Met je laatste zin ben ik het helemaal met je eens. Alleen: Ik weet niet waar de bug zit, je gaat er al van uit dat het in het timezone management zit. Misschien zit het ergens anders is de bug zelf best eenvoudig te fixen.

Niemand behalve Apple weet exact waar het probleem ligt. Het enige wat we weten is dat er ergens een berekening wordt gedaan waardoor er waarschijnlijk een underflow plaats vind, zie ook het meermaals aangehaalde filmpje van Tom Scott. Wat nu als de berekening die fout loopt de berekening is van je laatst ontvangen telefoontjes? Stel je bent 5 dagen geleden gebeld en er wordt inderdaad berekend wanneer dit geweest zou zijn:
1/1/1970 -5 dagen=error. De minimale datum zetten op 2/1 heeft dan weinig zin.
Je zal dan als (tijdelijke) fix inderdaad een veel grotere marge nodig hebben, (neem meteen 5 jaar ofzo) maar uiteindelijk loop je tegen hetzelfde probleem aan. Op lange termijn zal de bug zelf gefixt moeten worden.

Er is geen enkele indicatie dat er een ander probleem is dat moet opgelost worden. Je zal zien: de tijd zal na de fix niet meer op de bewuste tijd in 1970 kunnen gezet worden.

Meer marge nemen? En er een dag nadat je de fix uitrolt achter moeten komen dat er toch nog iets je marge overschreid. Iets met Murphy.

Ik ook niet, maar t feit dat het kan en dat je apparaat op zwart gaat is natuurlijk not-done. je hebt altijd wel van die slimmerikken die een geintje uit willen halen en jou toestel in de boot-loop gooien. Zit je mooi met de gebakken peren.

Keurig van Apple dat ze zo snel reageren en een patch uitbrengen.

Het is ook niet zo dat je het eventjes vlug kunt doen. Er zijn meerdere stappen voor nodig.

Een open wifi netwerk opzetten met een fake NTP (om de tijd te synchroniseren) is genoeg

Het zou een vreemde NTP implementatie zijn die dat zou accepteren. Doorgaans negeren NTP clients responses van servers te teveel afwijken aangezien dat een aanwijzing kan zijn dat die NTP server niet goed werkt of malafide is.

Dat niet alleen. Ze moeten ook hun iPhone opnieuw opstarten terwijl het op die tijd staat. Want eenmaal terug in het 'normale' netwerk staat de tijd weer goed.

Waarom zou dat werken ?

Ik vind het raar dat als je software uitbrengt op een bepaalde datum de software toch ondersteuning heeft om een tijd in te stellen van voor de release. Wat wil je er mee testen? Als je het als dev niet kan kunnen gebruikers het ook niet.

Er zijn altijd gebruikers die het wel doen, wat voor reden ze er ook voor hebben. Een oude iPhone gebruiken als leeftijdsindicator. Of als je bepaalde apps die het niet meer doen na een bepaalde datum wilt blijven gebruiken. Het maakt ook helemaal niet uit wat de reden is dat gebruikers het doen of willen, ze zijn er. Niet dat je daar als Apple beslist rekening mee moet houden, maar een bootloop is wel een vrij ernstige vorm van geen rekening mee houden...

Ik wou terug gaan naar de jaren 60 ... je weet wel Woodstock en de maanlanding en zo ... maar mijn iPhone vond dat blijkbaar niet zo leuk .

Mensen proberen altijd dingen. Soms uit nieuwsgierigheid, soms omdat ze vreemd gedrag in de software opmerken. Dan kom je tot vreemde probeersels en verzinsels waarvan dit er 1 is. Dat je de datum zo ver kan terugzetten hoeft ook niet direct een probleem te zijn. Apple heeft er aan gedacht om bij het instellen een negatieve datum onmogelijk te maken. Je kan niet verden dan 01-01-1970, maar blijkbaar heeft een andere programmeur, van een ander stukje software ergens een controle vergeten te plaatsen waardoor die een integer underflow veroorzaakt.

Is dit niet ongelofelijk makkelijk op te lossen door ervoor te zorgen dat iOS niet toestaat dat je verder teruggaat dan bijvoorbeeld 1981? Of denk ik nu te makkelijk?

Je hebt een programma dat de datum instelt. Als je daarin de grens van 1981 er in zet, dan loop je het risico dat als er bij iOS een nieuwe UI komt met een nieuw programma, dat dan hetzelfde probleem weer optreed omdat de nieuwe programma vergeet 1981 er in te zetten. Bovendien heeft Apple zich weleens eerder twee keer aan dezelfde steen gestoten. (Met de wekker om precies te zijn). Beter is om de achterliggende bibliotheek aan te passen. Als dat mogelijk is. Als die bibliotheek al een beetje houtje-touwtje is geworden dan is het een optie.

Het feit dat iOS ooit een geüpdatet uiterlijk krijgt in de toekomst, wil niet automatisch zeggen dat de Settings gelijk van de grond af herschreven moet worden, of vervangen moet worden door een compleet nieuwe app. Het aanpassen van interface elementen is vaak al genoeg tenzij je echt iets radicaal anders van plan bent. Apple is doorgaans meer van graduele aanpassingen.

[Reactie gewijzigd door n-evo op 16 februari 2016 11:24]

Ik kan me herinneren dat ik op mijn oude Macintosh SE de datum ook niet voor 1970 kon zetten. Kennelijk hebben ze die datum meegenomen van macOS in iOS. Ik vind het wel lollig.

Unix-tijd begint met tellen op 1-1-1970 en kan niet negatief