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.
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 …
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.
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.
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.
"
"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.
"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.
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.
"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
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 :)
This post has been deleted by its author
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.
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.
"
"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.
So, what happens if you set the date to Saturday, October 22, 4004 BC, 6pm?
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.
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. :-)