Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Security Wireless Networking IOS Iphone Apple

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.
This discussion has been archived. No new comments can be posted.

iOS 1970 Bug Is Back, Can Be Exploited Via Rogue WiFi Networks

Comments Filter:
  • Guy takes himself way to seriously, as if this exploit can be used to compromise a remote ICBM launch pad or something.
  • by xxxJonBoyxxx ( 565205 ) on Thursday April 14, 2016 @10:39AM (#51908091)
    Forget "rouge" WiFi networks - now IT can finally strike back at BYOD users who insisted on connecting their iPhones into an internal corporate network. :)
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

      • 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.

    • Well you shouldn't be allowing their devices on your internal network if you don't want them. Packetfence comes to mind....... but there's plenty of other easy to implement solutions to resolve rogue devices connecting with legit credentials.
    • Forget "rouge" WiFi networks

      And then there's the eyeliner networks and the foundation networks to worry about.

    • Wouldn't it be easier to just do your job?

      • >> Wouldn't it be easier to just do your job?

        Found the PHB. C'mon people, it's almost Friday - lighten the fuck up.
  • Apple genuii (Score:5, Insightful)

    by Impy the Impiuos Imp ( 442658 ) on Thursday April 14, 2016 @10:43AM (#51908125) Journal

    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)

      by pushing-robot ( 1037830 ) on Thursday April 14, 2016 @10:56AM (#51908299)

      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

      • No, fire their damage control department, instead. They're doing a terrible job of minimizing the issue.
        • by phayes ( 202222 )

          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.

      • 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!!

        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

      • +1 for "eleven" - did actually lol at that! :D
    • by AmiMoJo ( 196126 )

      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.

      • by gwolf ( 26339 )

        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

        • 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.

          • 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?

      • 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...

        • by robmv ( 855035 )
          • NTP authentication [ntp.org]

            Yes that might help. In the 'near' future.

          • 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

    • We've already seen what happens when do don't do basic sanity checking on the upstream NTP data [slashdot.org]

    • by afidel ( 530433 )

      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)

        by tlhIngan ( 30335 ) <<ten.frow> <ta> <todhsals>> on Thursday April 14, 2016 @11:53AM (#51908715)

        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).

        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.

      • by Pyramid ( 57001 )

        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)

    by blazer1024 ( 72405 ) on Thursday April 14, 2016 @10:43AM (#51908131)

    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.

    • Yeah it came off confusing but I think we were supposed to figure it out from: "OS 1970 Bug Is Back" back, meaning it's the same bug. It is NOT clear that this bug doesn't affect 9.3.1 from the summary, the article linked though states it's clearly. This is the new slashdot, at least this one is kinda relevant to geek news
    • 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)

    "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 li
    • Re:umm what? (Score:5, Insightful)

      by frnic ( 98517 ) on Thursday April 14, 2016 @10:55AM (#51908283)

      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.

    • 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

      • 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.

    • by AmiMoJo ( 196126 )

      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

  • by Anonymous Coward

    ...the device is not permanently and irreversibly bricked?

  • by Anonymous Coward

    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)

    by pushing-robot ( 1037830 ) on Thursday April 14, 2016 @10:46AM (#51908169)

    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.

  • by Anonymous Coward

    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!"

  • 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?

    • by darkain ( 749283 )

      Simple, someone was just testing edge cases. https://en.wikipedia.org/wiki/... [wikipedia.org]

    • 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...

        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.

    • by marciot ( 598356 )

      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.

  • "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*

    • by Anonymous Coward

      "Permanently and irreversibly bricked", as in "plug it into your computer, start it in recovery mode, and restore your most recent backup".

  • 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.

    • 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...

  • 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?

    • 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.

  • I prefer this 1970 bug [lanciaflavia.it], of course!

You can not get anything worthwhile done without raising a sweat. -- The First Law Of Thermodynamics

Working...