back to article iOS 'date bug' can be exploited over Wi-Fi using NTP

Back in February, Apple nearly fixed the “1970” date bug that bricked iDevices running 64-bit iOS 8 or higher when their clocks were set to January 1, 1970. Apple blushed red and issued a patch, but according to PacketSled's Matt Harrigan and Critical Assets' Patrick Kelley, “you missed a spot”: the bug can still be triggered …

  1. bazza Silver badge

    Unbelievable. It's such an easy exploit to avoid.

    If nothing else an NTP client should never accept a time that's wildly different from what the client' own RTC is saying.

    1. Lyle Dietz

      A better fix is that software shouldn't start burning more cycles just because the system time is 45 years out.

      Has anyone tried using this hack to set the year to 2038 or beyond?

    2. AMBxx Silver badge

      client should never accept a time that's wildly different

      In Windows Server, the timeserver only accepts a change of up to one hour by default. Pretty sure the various strains of Unix are similar (presumably OSX too).

      Very surprised that iOS will accept it - the original error was when a user manually set the time, not via NTP.

      1. Anonymous Coward
        Anonymous Coward

        Re: client should never accept a time that's wildly different

        Yes, this one was a much worse bug because it could impact anyone. The previous was more of a "you do something stupid, you deserve what you get" kind of thing.

        It also shows the more general need for widespread support for DNS authentication. It is stupid to the extreme that Apple's NTP would blithely accept any date given to it no matter how much the phone's idea of the current date differed, but the fact that it is so easy to feed any device, whether Apple's or Google's or Microsoft's, bogus data by running a rogue DNS server is a problem shared by everyone. Its 2016 and still hardly anyone uses DNSSEC. Rogue DNS servers are the basis of the majority of MITM attacks, yet we are hardly any closer to resolving that issue than we were a decade ago.

        1. Anonymous Coward
          Anonymous Coward

          Re: client should never accept a time that's wildly different

          NTP is unauthenticated. DNSSEC won't help if you can set up a server which will service the IP address that the DNS hands out.

          time.apple.com resolves to 17.253.x.x (lots, in a round robin config)... it would be trivial to set up a device locally to impersonate those addresses.

        2. Anonymous Coward
          WTF?

          Re: client should never accept a time that's wildly different

          How will DNS help? NTP is not part of DNS.

          1. Tom Chiverton 1

            Re: client should never accept a time that's wildly different

            "How will DNS help? NTP is not part of DNS."

            No one enters NTP address as raw IPs...

            1. Cynic_999

              Re: client should never accept a time that's wildly different

              "

              "How will DNS help? NTP is not part of DNS."

              No one enters NTP address as raw IPs...

              "

              And? The malicious network can simply examine all packets and return a bogus reply (with spoofed IP address) whenever it gets any NTP request. DNS requests would be passed unhindered and receive the correct IP address.

      2. Anonymous Coward
        Anonymous Coward

        Re: client should never accept a time that's wildly different

        "Very surprised that iOS will accept it "

        Phones being portable devices get taken all over the world which means the time could have changed by up to 12 hours after landing. You could get users to manually set the new time themselves but most would forget or not bother then complain when all their alarms didn't go off at the right time.

        1. commonsense

          Re: client should never accept a time that's wildly different

          Yeah but if you fly to Australia from the UK, in Australia, your phone will still connect to time.apple.com. You get the same result back, so there's no shift in time. Your phone adds the 11 hours or whatever once it knows what timezone it is in via the phone network.

        2. js1592

          Re: client should never accept a time that's wildly different

          The time doesn't actually change. The phone's locality does, and it adjusts the difference from UTC accordingly.

        3. Midnight

          Re: client should never accept a time that's wildly different

          "Phones being portable devices get taken all over the world which means the time could have changed by up to 12 hours after landing."

          Um, that's not really how time zones work. Or time, for that matter.

          If you set your iToy's time zone to "Eastern USA", and it checks in with time.apple.com, it will retrieve the current time from San Jose, California as UTC, and then display it as US Eastern time.

          If you then fly to Western Australia, it will still be checking in with time.apple.com, still retrieving the current time from San Jose, CA, still as UTC, and still displaying it as US Eastern time. Even if you adjust the time zone through the control panel or have it set to adjust automatically based on location data, that only affects how the time is displayed. The internal clock shouldn't have to change at all no matter how many times you fly around the world

          1. Anonymous Coward
            Anonymous Coward

            NTP unauthenticated

            The only real solution to this problem is to create a new encrypted NTP protocol - the same as the current one except that the messages from the iPhone to the server are encrypted with a public key that only the NTP server having the private key can decrypt, and replies with messages encrypted with that private key which the phone can decrypt using the public key.

            The encryption would need to be in both directions to avoid a replay attack.

            Then they can sit back and listen to the howls of protest from people who complain that Apple is abandoning the NTP standard in an attempt to lock their customers in :)

      3. This post has been deleted by its author

    3. druck Silver badge

      bazza wrote:

      If nothing else an NTP client should never accept a time that's wildly different from what the client' own RTC is saying.

      So if your RTC or it's battery has failed, that's your device screwed?

      Likely as not if the RTC isn't working, it will give a default date way in the past, and the NTP client should bring it back to the present once the network is up.

      1. bazza Silver badge

        So if your RTC or it's battery has failed, that's your device screwed?

        Likely as not if the RTC isn't working, it will give a default date way in the past, and the NTP client should bring it back to the present once the network is up.

        In such a rare fault scenario it is not unreasonable to ask the user to manually set the time about right first.

        1. Cynic_999

          "

          "So if your RTC or it's battery has failed, that's your device screwed?"

          In such a rare fault scenario it is not unreasonable to ask the user to manually set the time about right first.

          "

          Huh? Many devices these days lose their RTC if the battery is dead or removed for longer than a certain time (could be immediately, minutes, hours or days). RTC's used to be backed up by their own battery that would last years, but most devices these days either have no backup supply, or use a supercapacitor to keep the RTC going through a battery change, and that doesn't last all that long.

  2. allthecoolshortnamesweretaken

    So, what happens if you set the date to Saturday, October 22, 4004 BC, 6pm?

    1. Anonymous Coward
      Anonymous Coward

      "So, what happens if you set the date to Saturday, October 22, 4004 BC, 6pm?"

      God's finger emerges from a cloud and presses the power on button?

    2. Anonymous Coward
      Anonymous Coward

      Don't they measure time in "AJ" (After Jobs) and "BJ" (Before Jobs)?

      1. Anonymous Coward
        Anonymous Coward

        Don't they measure time in "AJ" (After Jobs) and "BJ" (Before Jobs)?

        Given rumours over Silicon Valley executive excess, measuring the passage of time in BJs might make sense. It would also give us the opportunity to have a unit named after one of the world's greatest biologists - the Hooker.

        1. TRT Silver badge

          Re: Don't they measure time in "AJ" (After Jobs) and "BJ" (Before Jobs)?

          The unit would be the Tempus Jobs Hooker. Or TJ Hooker for short.

  3. Anonymous Coward
    Anonymous Coward

    Isn't it ..

    .. TIME they fixed this?

    Yes, yes, I'll go now. Someone had to say it.

    1. TRT Silver badge

      Re: Isn't it ..

      Time is an illusion. Lunch time, doubly so.

      1. Stoneshop
        Coat

        Re: Isn't it ..

        Well, the programmers were clearly out to lunch.

  4. Anonymous Coward
    Anonymous Coward

    Off to Heathrow tomorrow

    Might go early to have some fun. Create a "Heathrow FeeWifi" hotspot.... Also have some glasto tickets too, an even bigger influx of braindead gulible hipsters carrying their holy status symbols.

    Should be able to run the pi zero for quite a while on a portable supply. :-)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like