Slashdot Mirror
iOS 1970 Bug Is Back, Can Be Exploited Via Rogue WiFi Networks (softpedia.com)
An anonymous reader writes: Back in February iOS users noted that setting your phone/tablet's date to January 1, 1970 would permanently brick their devices. After Apple fixed the issue in iOS 9.3.1, two security researchers have now uploaded a video on YouTube showing how to exploit this bug from a remote location, with no access to the user's phone. The setup involves attackers putting up a Wi-Fi network on which they're running a rogue NTP server. This server tells iOS devices syncing their time that it's December 31, 1969, 23:59:00. Twenty minutes later, if the battery didn't catch fire (which is possible with this new exploit), the iPad or iPhone device is permanently and irreversibly bricked.
Guy takes himself way to seriously, as if this exploit can be used to compromise a remote ICBM launch pad or something.
Forget "rouge" WiFi networks - now IT can finally strike back at BYOD users who insisted on connecting their iPhones into an internal corporate network. :)
Fire the engineers who "fixed" this.
The fix should not just be prevent the user from setting the problematic time, but fixing the issue directly should the time become the bogus time by any means.
If the battery can catch fire, then you really, really, really need to fix it properly.
And the testers need a slap, too. One test case should have been setting the time by force to see what happens, and not just testing the time set lockout.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
>> They want mandatory prison terms for programmers that fix software bugs.
:)
I'll have to look into that. Maybe I'll finally get some peace and quiet - it can't be worse than an "open concept" office.
So the summary (and the headline) seem to imply that this bug affects even devices with iOS 9.3.1, but the article actually states:
If the device was running an iOS version vulnerable to the 1970 bug, after a minute, the device would reach the problematic crash date.
Kelley and Harrigan recommend that users update as soon as possible to iOS 9.3.1.
This is actually just a remote way to exploit this bug, and not a new bug as the summary suggests.
"Twenty minutes later, if the battery didn't catch fire (which is possible with this new exploit), the iPad or iPhone device is permanently and irreversibly bricked." How exactly does changing the system time via NTP cause the battery to catch fire? While I'm fully onboard with hating ios and most things apple does..... I'm not exactly sure how that statement makes any sense. I'm going to tell you right now, changing the date on my windows device and android device does not, in any way, affect battery life or heat. At all. The fact that this is even possible means there's a massive code issue in relation to the battery. Under what mechanism does the date and time have any effect on the battery drain? It simply makes no sense. Than again, the same can be said for the system becoming unresponsive AT ALL due to the fucking date. This is half-assed work at best. I expect a lot of bullshit from apple, but half assed stuff like this is not one of those things.
...the device is not permanently and irreversibly bricked?
Modern app appers know that ONLY apps can app apps, so if you use an appy app time server instead of LUDDITE NTP, everything will be super appy!
Apps!
If it wasn't clear, the bug was fixed in 9.3.1 - this only affects devices that haven't been updated.
Also, I think the highest temperature recorded was 54C... not something you'd want to touch, but not likely to catch fire either.
Finallly, if it's like the previous exploit, the device isn't completely bricked... when the battery goes dead or is disconnected the device can be reset.
How can I believe you when you tell me what I don't want to hear?
.. now.
You must hate yourself.
I've been fired from two jobs for fixing too many bugs. Pukianz don't need a law to force capitalists to make horrible products so that consumers are forced to upgrade. Those people make bad software on purpose.
Apple customer complaint: "Every time my phone tries to time travel, it overheats the battery and then bricks!" Apple Genius: "It's really simple. Time traveling requires infinite amount of energy, which your phone tries to pull from the battery. Unfortunately Apple batteries don't provide such amount of power at this point. Have a nice day!"
Great jorb, guys.
Sure, this sounds like a nasty bug but how did someone go about discovering it? Is this some tinfoil hat theory that setting the date to 1970 keeps the NSA from snooping your calls?
It's a feature!
"Twenty minutes later, if the battery didn't catch fire (which is possible with this new exploit), the iPad or iPhone device is permanently and irreversibly bricked."
Okay, I gotta hand it to Apple- that's innovative as hell! What a way to drive new sales.
"It Just Works" *cough*
Just cruising through this digital world at 33 1/3 rpm...
Does the rouge network need to dnsmasq time.apple.com? Or could this be accomplished by just passing on a DHCP option on the network to trust a local NTP server? Obviously setting up a dnsmasq makes the exploit more difficult.
Roughly have of the iOS devices that are controlled by my BES12 server are running versions older than 9.3.1.
"A plan fiendishly clever in its intricacies"- Homer Simpson
Doesn't the NTP specification have something about how devices are supposed to ignore NTP updates that are X number of minutes different than the current time the device has?
Why don't the Apple IOS devices do this?
Sure, this sounds like a nasty bug but how did someone go about discovering it? Is this some tinfoil hat theory that setting the date to 1970 keeps the NSA from snooping your calls?
It was mostly discovered because it's trivially obvious that any method of setting the date on the iPhone is functionally equivalent to any other method of setting the date, and that as such, you can exploit the bug from any time set method that the device supports.
We even discussed this in several forums already, and the fix is to update to 9.3.1, since they are only exploiting a bug that already existed. Further, it still only exists on 64 bit iPhones (32 bit iPhones are "safe"), and it can also be exploited by emulating a cell tower, instead of emulating a WiFi hot spot that the iPhone already trusts, since all cell phones pretty much trust the time stamp sent by cell towers.
Not at all ironically, you have to asymptotically approach the time, as well, since NTP has built in protections against a large time drift in the first place; the cell tower attack technically doesn't use NTP, and so would not have this "problem".
Pretty much, this is a "nothing to see here".
Slow news day before income tax day, anyone?
Also...
No danger of fire or permanent bricking, either. 50 C is far lower than the flashpoint of anything but an accelerant, and drain or disconnect the battery, and the problem goes away, just like before.
This. They want to take our iPhones.
How hard would it be to take an ESP8266 module with a battery, have it broadcast a fake ESSID, and serve the killer NTP packet? Say, spoofing Starbuck's SSID? Or McDonalds? I'd bet you kill a lot of un-upgraded devices that way... At maybe $2-$3 each, this is in the disposable range.
Seems like a fairly quick and effective way to permanently deny access to your phone should anyone get their grubbies on it without your approval...
In this day and age it would seem like smoke signals might be an excellent choice for communication.
Sure, everyone can see them, but iphones, blackberrys, android devices are all very leaky insecure devices anyway - regardless of what "the man" might tell us.
IF NEW.DATE CURRENT DATE - 2, goto INVALID.DATE
then the invalid date subroutine ignores further attempts to alter the date.
FTFY
Was contemplating this. Would it be a good idea if an SSID was accompanied by some trust metric, like a certificate chain? Then, if a device is going to maintain a list of known WiFi networks (which is handy), it can do certificate checking to make sure it's not just a network called 'attwifi', but actually is signed by AT&T.
Obviously, some DHCP parameters would be ignored until the SSID is verified, as well as holding back normal traffic.
Oh my god. Apple actually implemented the HCF instruction?
I prefer this 1970 bug, of course!