iOS 1970 Bug Is Back, Can Be Exploited Via Rogue WiFi Networks (softpedia.com) 106
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.
Re: (Score:3)
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.
LOL at the sound track for the exploit video (Score:2)
Re: (Score:3)
A simple bug in Apple's software is much different than a trojanized payload.
Also Good for Corporate WiFi Networks (Score:5, Funny)
Re: (Score:3, Insightful)
If the IT department setup their network in a way that allows these devices to connect then the problem is the IT department, not the employee.
Re: (Score:2)
If the IT department setup their network in a way that allows these devices to connect then the problem is the IT department, not the employee.
Correct. Anyone who is running a PSK wireless environment on their corporate network deserves what happens. Use certificates, AD membership, etc to authenticate.
Re: (Score:2)
Re: (Score:2)
And said C level executive will say (if you are lucky) "Here's X amount of dollars. Make it work, I want to be able to use device in meeting next Wednesday." I can guarantee you that X is going to be less than the amount needed to do it properly and a performance goal will be added to said IT guy's yearly review showing how well they made it work (or not work).
Re: (Score:3)
Forget "rouge" WiFi networks
And then there's the eyeliner networks and the foundation networks to worry about.
Re: (Score:2)
The nail polish networks are truly terrifying though.
Re: (Score:1)
Wouldn't it be easier to just do your job?
Re: (Score:2)
Found the PHB. C'mon people, it's almost Friday - lighten the fuck up.
Apple genuii (Score:5, Insightful)
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.
Re:Apple genuii (Score:5, Informative)
No, fire the summary writer.
The bug was fixed, this is just a practical way of exploiting devices running the affected versions.
Also, there have been no battery fires, but aluminum feels pretty hot when it gets to 50C and people assumed their phones must be OMG about to CATCH FIRE!!11!!eleven
Re: (Score:2)
Re: (Score:2)
Nope, the problem only exists in the mind of the people who like to hate on Apple and jump to false conclusions on unsubstantiated reports. There is no fixing these people.
Re: (Score:2)
Not sure what Apple fanblog has been spreading that nonsense. Anyone familiar with Lithium-ion chemistry [batteryuniversity.com] can tell you unequivocally that charged Li-ion batteries can catch fire [youtube.com] when damaged or overcharged. You'd be a fool to dismiss it as anti-Apple rhetoric - click on related links to other brand Li-ion batteries catching fire if you feel this is some
Re: (Score:1)
Re: (Score:2)
It's not just the engineers who were supposed to have fixed the 1970 issue, it's the ones who thought it would be a good idea to connect to random NTP servers and blindly accept their claim that time travel has been invented and it's now the 1960s, only now they have wifi and NTP.
Re: (Score:2)
That, or maybe the fact that the phone was left unplugged on a drawer until somebody's grandchild connected it after January 2038 just to see what is that thing.
Of course, your comment still applies: It's probably impossible to travel back to 1969 and have working wifi and NTP. But I think it's highly unlikely that by 2038 we will have Wifi networks compatible with today's standards, or NTP servers compatible with today's implementations.
Then again, today's Wifi is still compatible with what 802.11b, which
Re: (Score:2)
Actually I bet current devices 2016 will still connect to the same wifi in 2038.
Remember wifi 802.11b came out in 1999 which makes it 17 years old.
2038 is only 22 years away. 801.11n and ac will still be around.
Re: (Score:2)
Re: (Score:2)
Actually I bet current devices 2016 will still connect to the same wifi in 2038.
Remember wifi 802.11b came out in 1999 which makes it 17 years old.
2038 is only 22 years away. 801.11n and ac will still be around.
But...but...what standard will the hoverboard I've been promised run on?
Re: (Score:2)
It's not just the engineers who were supposed to have fixed the 1970 issue, it's the ones who thought it would be a good idea to connect to random NTP servers and blindly accept their claim that time travel has been invented and it's now the 1960s, only now they have wifi and NTP.
What I'd do is set up to capture all DNS traffic and direct it to my own DNS server and return my own NTP server for any requests for the NTP servers that iDevices are typically configured to use.
No need for 'rouge NTP servers'.
However, checking that the amount of time change that the NTP server is asking for is within sane parameters is normally normal...
Re: (Score:2)
NTP authentication [ntp.org]
Re: (Score:2)
NTP authentication [ntp.org]
Yes that might help. In the 'near' future.
Re: (Score:2)
The issue with this is that I'm pretty sure NTP authentication is bidirectional by IP address.
That means Apple would need a unique key for every iOS device, and they would somehow have to dynamically update their current IP.
NTP authentication is pretty broken IMHO. I wish it were something that was one-way, where the clients can just have a trusted signature installed and validate the timestamp. It isn't critical to hide the NTP info from snooping, just to validate that the timestamp has been issued by a tr
Re: (Score:2)
Follow the link, there is Public-Key Authentication now
Re: (Score:2)
Nice! I've yet to see this implemented, but glad to see it is being worked out.
Re: (Score:2)
We've already seen what happens when do don't do basic sanity checking on the upstream NTP data [slashdot.org]
Re: (Score:2)
This is true. Also WHY is the ipad following NTP if the slew rate is greater than 500ppm? The NTP RFC's clearly states that this is the maximum you should adjust the clock via the protocol(s).
Re:Apple genuii (Score:4, Informative)
NTP has two modes.
First is to keep clocks in sync, so if you have a network of devices, the clocks can tick pretty much together. This is what you use NTPd for - to keep clocks on a network in sync.
The other use is to set the clock, which uses the same protocol, except we call it "daytime protocol" because they do an NTP query to get the current date/time to set it. In Linux, you use "ntpdate" to set the clock initially since NTPd will refuse to run if the system clock and server clock are too far apart. So you use ntpdate to get the clock close enough.
Most devices when you set "Automatically set date/time" use daytime to set the clocks. It's only stuff like the Apple watch (which is used to keep time) that generally wants to keep time in sync.
Re: (Score:2)
Because like most portable devices, they probably aren't running a full ntp daemon/stack, but an SNTP client that periodically queries a single time server and sets the device's clock to whatever the reply contains. At a bare minimum, they should query several quasi-random servers like pool.ntp.org (style) at the same time. It would make an attack like this more difficult. And or perform a sanity check using the following pseudocode:
If date Skylab leaving crater in Austrailia
Bad Summary? (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
That's a horrible clickbait summary.
Hey your phone will catch fire! We'll throw some mumbo jumbo about NTP to scare you. Please come click on this story, and oh by the way disable your adblocker...
umm what? (Score:2, Insightful)
Re:umm what? (Score:5, Insightful)
Don't let you hate blind you, this is NOT a new exploit, this is the same exploit and is fixed in 9.3.1 and the article even suggests updating to prevent it.
Re: (Score:2)
Maybe the system has direct control over the charger circuit, so if it locks up while the battery is being charged, it won't stop charging?
Maybe it's just the temperature sensor, which is monitored by the system, so if there is any problem with the battery overheating, the safety does not trigger?
There are countless possibilities how this may occur. The bug bricks the system, so it seems to be pretty low level.
None of this should be possible in a proper designed system, but then again the initial bug is red
Re: (Score:1)
Maybe it's just the temperature sensor, which is monitored by the system, so if there is any problem with the battery overheating, the safety does not trigger?
I'm pretty sure there's something to this. Periodically my iPhone 5S becomes hot enough to be very uncomfortable to hold while charging, and a power cycle cures the issue. Personally I think it's awfully daft to have something as important as a Li+ battery temperature sensor dependent upon the OS rather than being a separate, independent component.
Re: (Score:2)
The bug causes some kind of infinite loop that heats up the CPU. Cooling in phones is fairly marginal and they can't run at 100% constantly. They have thermal protection that shuts the device down if it gets too hot, or on other CPUs throttles the core frequencies back. I don't know if Apple have the throttling, it can affect benchmark results so maybe they decided that it would happen rarely enough not to worry about.
Anyway, the infinite loop uses lots of power, draining the battery, and converts much of i
So if the battery does catch fire... (Score:1)
...the device is not permanently and irreversibly bricked?
Re: (Score:3)
No, it's permanently and irreversibly burned.
Re: (Score:3)
No, at that point it's briquette.
This is caused by LUDDITE NTP servers! (Score:1)
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!
It was fixed... (Score:5, Informative)
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.
Time Travelling (Score:1)
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!"
How was this discovered? (Score:2)
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?
Re: (Score:2)
Simple, someone was just testing edge cases. https://en.wikipedia.org/wiki/... [wikipedia.org]
It was trivially obvious. (Score:2)
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 explo
Also... (Score:2)
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.
Re: (Score:2)
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?
Obviously someone whose software license has expired.
Wow (Score:1)
"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*
Re: (Score:1)
"Permanently and irreversibly bricked", as in "plug it into your computer, start it in recovery mode, and restore your most recent backup".
Question on iOS and NTP (Score:2)
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.
Re: (Score:2)
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.
Redirecting DNS traffic, or NTP for that matter, is not difficult. No need for DHCP, a simple iptables rule will do this in about one line...
"Insane" NTP servers (Score:2)
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?
Re: (Score:2)
Interestingly enough, CentOS 6, and therefore probably RHEL 6, has a ntpdate startup service as well as an ntpd startup service. As suggested by the name, the ntpdate service executes the ntpdate cli to force a full time sync with the servers in ntpd.conf.
That isn't there in CE5. And at least it is off by default, but someone decided it was a good thing to force a time resync at boot.
IOS probably followed this model for some reason.
Re: (Score:2)
Base minimum Centos 6 doesn't have ntp installed, but the RPM is in the base repository and doing a yum install ntpd gives me both, and an ntpd.conf.
Re: (Score:1)
IF NEW.DATE CURRENT DATE - 2, goto INVALID.DATE
then the invalid date subroutine ignores further attempts to alter the date.
FTFY
So if you set someone's date forward 15 years, they can't set it back?
Re: (Score:1)
I prefer THIS 1970 bug (Score:2)