I learned about this yesterday from a Tom Scott video (https://www.youtube.com/watch?v=MVI87HzfskQ). I find it odd that his sources are suggesting that this is an integer underflow bug. First, while integer underflow itself would be a bug in this case (if it's occurring) the real bug would be not handling large time values. If they are indeed using u64 to store time, the system should be designed to, you know, handle u64. Why would parts of the system break for values like 0xFFFFFFFFFFFFFFFF?
Second, and this is more important, iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed. No underflow involved. It just literally goes negative. And this is far more likely to be the cause of the issue. In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) < 0) { halt_and_catch_fire(); }` or `while (time(NULL) < 0); // wait for RTC to start up`. That's more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.
The take away? My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don't return negative values as error codes. Wrap broken functions like `time` into functions that return the time and an error code separately. If you'll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it's worth representing.
All we know is that boot-up fails on 64-bit hardware. We don't have nearly enough information to accurately guess which boot-time component is failing or what API this component is using.
A trivial example would be casting an `unsigned int` to a `time_t` (i.e., `long`). It will work with negative numbers on 32-bit systems, but will fail with negative numbers on 64-bit systems.
Introducing the iPhone 7. It's the first iPhone specifically engineered to withstand the Sun exploding in 7 billion years' time, and we think you're going to love it.
> In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing […]
Particular in this case which traditionally is a function which does not indicate failure by setting `errno`. On many systems it's impossible to distinguish a second before epoch with a legitimate failure.
I think of this another way: why should a "get current time" function ever return an error? And what is someone to do about that case anyway? The time it returns may be wrong, but I think such a function shouldn't be capable of returning "error", as adding that path just increases complexity needlessly without much additional benefit; with the current time being used often in things like error logging, introducing an "error on top of an error" is not a good idea. Defaulting to January 1, 1970 or December 31, 1969 would be sufficient.
If you look into the glibc sources you will find time() implemented as always returning -1. Not all systems have a clock. So specifically for linux for instance it will ask the os for the time.
You know, the sad thing is even though I fall into the set of folks who "don't need that video", I can't figure out how to set the year on my iPad's date.
Not permanently. Some report that it fixes itself after time, but the most widely accepted solution is to let your iPhone battery die. It seems to fix this bug every time.
The Zune bug was persistent though, and caused by the leapyear. Even if the battery drained it went straight to bootlock. But yeah, it did fix itself at midnight.
Before non-removable battery became mainstream, most phones had a small internal battery to keep the internal clock ticking when the battery is being swapped. This is not unlike the CMOS battery found on PC motherboards.
iPhones does not need this backup power since the battery is always attached. Hence in case the battery becomes completely drained the internal clock will reset. I can't recall what the default time iOS resorts to after a total power loss but IIRC it was a date well into the 2000s.
I fix iPhones. The battery needs to be really, really dead before it'll fix the issue. When a battery is reconnected the internal date is reset back to 0 (Jan 1 1970) until the phone connects to a cellular network/NTP server.
Wouldn't that result in the same outcome though? I find it more likely that the clock is reset to a more "sane" time - like Laforet stated as being "well into the 2000s".
It's not "simple" in the sense of removing a laptop battery, but it's among the simplest of repairs that are done to these devices and something virtually any service shop will be able to do for you in an hour.
And the explanation is surely that the RTC is backed by the main battery and gets cleared to some default state by this procedure.
Edit: For the sake of completeness, the deleted parent suggested that iPhones are unable to be opened because they're glued up, and doing so (to reseat the battery) would void the warranty
Nope.
(Former) Apple Retail 'Genius' here. iPhones are trivial to open up to get to the battery, provided the right equipment (tore screwdriver and suction cup + grip), and disconnecting the battery is just a simple tab/plug to lift up.
Because this isn't a 'modification' (Apple warranty forbids unauthorised third party modifications) and is exactly what they would do in Apple Store anyway, you're safe to do this yourself without voiding your warranty, as long as you know what you're doing.
How was customer data erased or prevented from later being perused by employees on those "bricked" phones customers have swapped out? Because customer data would still be intact if such a device were looked at by engineering or others with sufficient test equipment, especially on a device that didn't have a passcode.
Sometimes for an actual hardware service (say, replacing screen on iPhone), the customer will be asked to erase the data on the phone themselves before handing it over. This is to stress the point that they should have a backup, and so Apple can just quickly replace the phone if someone goes wrong with the repair.
But for something like reseating the battery, the main factor is they just don't care enough - the employees are trying to get through your appointment as soon as possible (customers seen/avg session duration is a metric they're measured on) and 99% of the time, they just aren't interested in the data on your iPhone to even try. Once they see the phone is powering up, they're done with it.
Then there's fear of retribution. Looking at customer's personal data is seriously prohibited, so you'll be in a lot of trouble if you get caught.
And of course, security. If there's a password on the device, there's simply no way for them to get further than the lock screen or access any data. Even if you're willing to believe a conspiracy theory that Apple technically can through a backdoor they've built into it (which seems highly unlikely given their crusading around this topic), there's no way in hell Apple would give the 50,000 underpaid paid Apple Retail employees access to a tool like that.
But at the end of the day, it's trust. "If an attacker has physical access, your system is already compromised". If you don't trust anyone else to handle your phone without trying to 'steal your data', then you should erase it yourself before handing it over.
Maybe I wasnt clear enough: what happens to these unfortunate folks that hand in bricked phones whom are unable to erase content? Refurbished by third parties, sent to engineering, recycled?
I am not sure about iPhones but opened all of my Macs before, sometimes to do some upgrades or clean up. It never voided warranty. All three had some work done by Apple. As long as you do not screw up yourself something during repair, it is fine.
I would expect majority of HN population to be able to follow step by step guides online.
True, but because there's no "warranty void if removed" stickers inside, you could open up the iPhone, unplug and replug(?) the battery, and close it up. Apple wouldn't be able to tell. Heck, I've replaced batteries in iPhones and they were taken into the store for other issues and they were covered under the warranty w/o a problem.
So, AFAIK, there's no warranty monitor to tell if the battery had been removed because that would almost certainly have false positives with phones that have fully depleted batteries. Sure, if you replace the pentalobular screws with the Phillips from iFixIt, they'd know you opened it, but if you put the pentalobular ones back on before going in, they won't be able to tell.
It doesn't matter anyway, they can't void your warranty just because you did some work on your phone. If you break something then of course that wouldn't be covered, but the warranty would still apply to everything else.
> Theoretically, attackers can send malicious NTP requests to adjust every iPhone's time settings to January 1, 1970
Just to be clear, this (typically) isn't possible. NTPD refuses to adjust the clock if the time difference is too large. (I don't recall what the default threshold is, but IIRC it's less than 24 hours, certainly less than 46 years.)
This is important for TLS - if an attacker could significantly roll back your system clock, they could trick your browser into accepting an expired certificate. Compromised certificates would be a problem forever, rather than just until they expired.
What if you crafted a program that mimicked the functionality of an ntp server, and but it had a built in memory of what times have been given out to network clients? Couldn't you in theory send a series of NTP answers that quickly stepped back the clock of the target system, with the stepback value being whatever the maximum value the ntp client will handle? Answer one subtracts the time by 24 hours, the next by another 24 hours, the next by 24 hours? Is there a limit to how frequently the time can be stepped back?
I once had an iPod touch disabled for millions of minutes after entering the wrong password too many times. Turns out the date was reset back, probably because it had died, while the "last pass enter" must have been set forward, and so it was waiting several years to allow another password.
On a similar note, you could get extra tries at the restrictions password by setting the date forward. Don't know if either has been fixed, haven't tried recently.
No programmer ever wished for more special cases when integrating date handling code, especially on a networked device and one that's so tightly integrated with other platforms and devices. And imagine the nightmare of testing the device pre-release, all while faking out the dates, both local and on NTP servers and on development desktop machines the under-development devices are tethered to, and somehow knowing exactly when the release day was going to be, possibly years in advance. So... no, I'm not sure about that plan. And I guess the bug would be unaffected in any case.
"bricked", "permanently bricked" seem to be the hardware world's "literally". Throw the words around and contradict yourself simultaneously. Who's keeping track?
I repaired a MacBook Pro which had been powered off for an extended time and couldn't load OS X onto it. Turned out it was using hardware time to determine if a cert was valid when validating the OS X install image. (Validation is done by the downloaded installer so I infer that it was trying to make sure the download was okay and was not trying to prevent third-party OS installs). I fixed it by spawning a shell from the installer and setting the date the unix way -- but what is a mere civilian supposed to do?
The ability of modern hardware to download install an OS directly from firmware is a truly great and useful modern innovation, but it leaves a lot of unanswered questions: What if my network is bad? What if this used hardware is stolen? What if I don't have an account? What if Apple goes bankrupt?
USB/SD/DVD installers do not require network access nor any sort of account/purchase verification, and can be created (relatively) easily and officially from downloaded installers. I have bootable disk images for every OS X installer since OS X Mavericks and I highly recommend it.
I'll include a USB installer whenever I sell an old laptop. It costs me next to nothing and gives the buyer some reassurance that they're not buying a brick. And if I decide to hang on to a piece of hardware, I have some assurance that I'll be able to use it 10 years from now.
Still not known or obvious to many, but less cryptic than a terminal to most: reset the NVRAM (aka PRAM). Hold command-option-P-R keys until you hear the startup chime for a second time.
Ah, of course not, since how can the default be set to the current time?
I almost always install after booting to a full OS X system on an external hard drive (so NTP syncs the time), either via a downloaded installer or after logging in to the wifi captive portal (since Internet Recovery won't do WPA Enterprise).
On Linux and Windows, the NTP update daemon "sanity checks" the new date. It refuses to update the time if the new time is "too far" from the current time. Is the Mac any different on this front?
"Mere" is a bit much. You're not an immortal superhero.
To answer your question: a non-technologist pays someone like you to fix it. Much like the way most people bring their cars to mechanics instead of spending hundreds of hours learning to fix the vehicles personally. This type of specialization is prerequisite to the large civilizations in which we live.
In this case fixing the issue required knowledge of how certs work in order to guess that there is a date issue. That's probably pretty rare at fix-your-computer shops.
It's pure luck that I'd seen this type of issue before because I'm one of those mere civilians: my Windows machine at work loses BIOS settings on power down. I've seen that until the date is restored, DropBox and several other things don't work.
I think that we can be more generous to a vendor who didn't test sufficiently for a failure mode that would be a legitimate use only to a (reverse) time traveller who wouldn't be able to connect the device to any network in existence in 1970 anyway. Seriously, people are complaining about problems when they go out of their way to set the date to a bogus value? Some behavior is its own punishment, people!
You mean a failure mode that is simply the time server saying "start of epoch, no offset"? There's a ton of ways for an offset to be zeroed by accident.
Hell, two years ago I was setting up logstash, and was wondering why none of my front-end searches were getting loglines. Turns out the front-end was expecting four-digit years and I was saving two-digit years - by widening my search to include the year 14AD (rather than 2014), there were my loglines.
I don't expect a vendor to intelligently handle this error and fix it for me, but I do expect a product not to irrevocably break itself if such an error does crop up.
Why allow you to set your own date anyway? The device should just talk to an NTP server. Wouldn't want a malicious human setting an incorrect date now, would we? That's dangerous!
What does "right month" and "right year" mean? Server time or local time? Either you're trusting the user's device, or your clock is always 12 hours off for some users.
I remember they thought Y2K would pose a challenge and everybody laughed it off afterwards. Could they have ever imagined bugs like these would become prevalent in the future?
We (at ring.cx) had a "Y2K" bug on Jan 1. Some old boring code was replaced with more "readable" one and "underflowed" (technically, it did not expect negative values).
I wonder if instead of it being an integer underflow issue, it has to do with a divide-by-zero issue (if something ever is divided by the entered date).
Second, and this is more important, iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed. No underflow involved. It just literally goes negative. And this is far more likely to be the cause of the issue. In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) < 0) { halt_and_catch_fire(); }` or `while (time(NULL) < 0); // wait for RTC to start up`. That's more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.
The take away? My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don't return negative values as error codes. Wrap broken functions like `time` into functions that return the time and an error code separately. If you'll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it's worth representing.