
The 1970s...
The decade that time and taste and Apple forgot....
Watch out: setting the time and date on an Apple iPhone, iPad or iPod to January 1, 1970, may brick the thing. In a Reddit discussion today, folks described how setting their device's clock back to that point in history resulted in a crash after which their iThing was unable to boot or be restored via iTunes. The bug affects …
I minor observation is that the at 00:00:00 01/01/1970 UTC, the local time in the UK was 00:01:00, for the UK was then on British Standard Time. Thus whilst PST then was 8 hours behind UTC, it was 9 hours behind London.
Timezones are, and always have been, a nightmare.
Why would anyone set their iPhone's time to 1/1/1970 when clearly, that isn't the present date? Are we just looking for ways to crash iPhones so that we can report on how doing something most people would never do can crash an iPhone? Surely, there is something most people would normally do that might crash an iPhone?
Wonderful way to prank someone or an Apple store, I guess. You can also troll people into doing it...
C.
Um, no. Somebody at Apple used the provided standard UI widget for date and time. (OTOH, if there's any company that could pull off "we're sorry you can't pick your date of birth on that web page, but we're using our standard widget which doesn't go back beyond (phone release year), it'd be Apple.)
brotherelf "Somebody at Apple used the provided standard UI widget for date and time."
Who provided the 'provided standard UI widget'?
Apple. The widget must have BEGINNING and END range settings.
Almost certainly, some dough-head typed in BEGINNING = 1970 etc. Because THEY DIDN'T THINK.
No matter how you slice and dice it, it's an explicit and monumentally-dumb error.
IIRC Nokias allowed the first of January of the OS's build year and only took time updates from the mobile network, yet calendar dates and birth dates could go back to 1/1/1900.
Still so much to learn down there in Silly Valley. If only they learnt it before launching their perpetual beta OSes.
This allows an NTP attack on almost any public wifi which permanently bricks your phone. All you have to do is supply DHCP time server responses to point to your own NTP server that sets the date to 1/1/1970. Or intercept the (plaintext) NTP request that it sends to ANY NTP server on your Wifi.
That's NOT expected, or sensible, behaviour and provides a dangerous, and costly attack. Imagine doing that at a conference. Hundreds of people join the free Wifi and bam, their phones are bricked.
This isn't a "non-issue". It shouldn't happen. As a school IT manager who's just sent the kids off for half-term with their 1:1 iPads (which are affected), this means I can expect at least half a dozen completely dead devices requiring Apple service (which we avoid like the plague) just because of a prank going round.
You can't rely on devices with such bugs. Now this is one bug, a bug that requires some setup (it DOESN'T require much user co-operation, note, just joining a public Wifi!), so the chance is low. But the damage is high. Your phone is bricked until, basically, you take it back to Apple. Or restore from a backup in a certain way (let's hope you have recent backups of your phone, right?). That means the impact is high.
So it's not "nothing". But it's certainly not the end of the world. However, for anyone managing Apple devices, or who doesn't want their phone to have to go back to an Apple store in order to ever work again, it's a huge pain in the butt.
I think it's important here to disambiguate the protocol NTP from the ntpd daemon offered by the folks at www.ntp.org.
The ntpd daemon by default ignores time offsets that are huge. BUT it's also a common practice to do an ntpdate in the script that starts the daemon to set the hardware clock first. I think this is to handle wacky-ass BIOS clocks and make it so network time Just Works.
The NTP daemon chronyd respects large offsets -- at least on startup (also I think during running, but I'm not as clear on that).
Long story short, you can't rely on rejecting large offsets to protect you.
This post has been deleted by its author
"As an easy way to find out what day is was on that date. I regularly use digital clocks/calendars to do that. It should NOT destroy anything."
Ok, so you've check what day it was on the 1st Jan 1970. Fine. Now why the fuck would you then set the OS clock to that date? The calender already tells you what you need.
Not tried it on a public WiFi - just tried it on our Test WiFi though. Our NTP server would, as previously mentioned, not let the time deviate by more than 1000 seconds.
So I commented out the pool servers so it only had the local IP of our NTP box, dropped the internet connection on the test network router just to be sure, set the system clock on the NTP box back to 1/1/1970 and then it went through fine and bricked one of our test iPhone 5C's.
So concept proven.
This post has been deleted by its author
Seconded. Which is why I write my dates as 13-Feb-2016. I'm an American, but its been over a decade since I last used our broken data format. Helps quite a bit when sending email to India since some places have started adopting the US data format, while others use the British format (hooray for outsourcing...)
I've used what I've known as the Japanese format for decades (which is what that ISO seems to refer to), because YY(YY)MMDD also happens to sort nicely along date lines. It's such a simple thing it's amazing it wasn't adopted globally.
I must admit I have found the US format exceptionally pointless. Does anyone have an idea what drove the adoption of that format? I mean, I can accept being blind drunk as an explanation, but I struggle to come up with a rationale for this as a deliberate choice :).
This post has been deleted by its author
Yup. YYYY/MM/DD. When people at work comment on the date format using words like weird" and say that nobody uses such a date format, I point to the photos printed and stuck on the wall in quality control. The camera burns in the date in exactly that format. And given the company deals with international clients some of whom use American dates and some who use European dates (and the ensuing ambiguities), I think the big endian format makes sense.
So. Have an upvote.
This post has been deleted by its author
This post has been deleted by its author
I believe it follows the formal writing format for dates.
Eg. Sunday, February 14 2016 = 2/14/2016
I suspect mm/dd/yy is an accepted abbreviated form of the date in writing and us Americans are too lazy to use different formats in non-writing situations.
I also use YYYYMMDD ordering for dates, since matches numerical with chronological file sorting. I avoid DDMMYYYY or MMDDYYYY like the plague simply because for the first 12 days in any month it becomes impossible to distinguish between US and normal date formats. I've had some really nasty errors crop up because some American customer provided 7/1/2007 as a payment date and my system parsed it as 7th of January instead of the 1st of July as intended (1st July is the first day of the financial year in Australia.)
To the point where, when I design ecommerce websites, all dates on orders, invoices, transactions etc, are displayed in YYYY-MM-DD hh:mm:ss format by default; the customer can change the date format if they wish (since the board insisted on providng the ability), but I've buried the date-format control so deeply in the CMS and made it such an utter bitch to do so, that most people simply give up trying and accept the sensible format. So my crusade to make the world adopt the logical year-first convention is coming on apace!
Agreed, so I always respond to the request, "Date of birth?" with "April first", never four-one or one-four, and also I date written documents the same way unless the the form specifies otherwise.
The dating confusion once gained me five months on a warranty repair though when I presented my original Walkman (remember them?) for repair and the repair shop interpreted the sales slip date opposite to its original meaning, month/day vs day/month.
"So the world according to Unix began on 1970-01-01"
Not at all. The folks who developed Unix knew about negative numbers. The cal command command, for instance, will calculate calendars for dates much earlier than that. Try cal 1752
They were an erudite lot (more erudite than VCs it seems). man cal in V7 Unix listed as a bug that taking Jan 1 as the beginning of the year was historically naive.
Not just an historical curiosity. The Government has not yet noticed that the year no longer starts at the First Point in Aries, currently around April 5th due to the accumulated errors prior to adopting the Gregorian Calendar. At least it makes accountancy software that handles wages that little bit more complicated and expensive.
It's a fairly complicated set of events. "Years" can start at different dates. Academic years (at least in the UK), for instance, start with the Autumn or Michaelmas (YMMV) term. The church's year started on the assumed date of Christ's conception, 9 months back from Christmas, i.e. March 25, Lady Day. That also became the starting date for a lot of commercial arrangements. However there was also a tradition that January 1st was the start of the year so you may well find dates in the first few weeks of the year being given along the lines of 1722/3. I know of one published early C18th diary which starts years in January and some years are labelled in that fashion and some in modern fashion.
England and colonies stuck to the Julian calendar long after many countries had gone over to the Gregorian (but not all at the same time) and by 1752 the two calendars were 11 days out of sync. This was solved by omitting 11 days from September so the calendar for the start of that month reads 1 2 14 15 16 and January 1st was set as the start of the year in accordance with the Gregorian calendar.
This introduced a potential problem with contracts. That was solved by having the contracts which covered that period run for the appropriate number of days. So a contract taken out on March 25 in 1752 would expire on April 4th 1753 and a new contract would start on April 5th. The "loss" of 11 days was problematic in itself so it's not surprising that nobody wanted to tinker with changing contract terms as part of the legislation. On the basis of not fixing what wasn't broken, nobody has tinkered with it since so the UK financial year still runs from April 5th - and try to visualise the complications and expense it would cause to change that now.
Of course businesses are free to arrange their accounting years whenever they like and if a business thinks it's a good idea to go through the accounting year turnover when everyone's feeling a little under the weather, good luck to them.
One would hope that setting up a nefarious NTP server would not in fact work - because good NTP clients generally refuse to change to the date and time supplied by an NTP server that would require a change across days and most that I have seen won't even change if the time is more than a few hours away from the currently set time.
Yes I saw what the flaw was - my point was that well designed NTP Clients would reject the spoofed time - because really good ones refuse timestamps that are more than about 2 hours from currently set time and most will reject timestamps that are more than 24 hours different to the currently set time. So providing that Apple coded the NTP client correctly - the phones should simply ignore any attempts to respond to an NTP request with a response of "0" (Though having said - whether the phone tries to resolve the timestamp after timezone conversion before rejecting it - thus potentially triggering a crash is an unknown at this point)
Isn't "providing that Apple coded the NTP client correctly" equivalent to saying "providing that Apple coded their clock client correctly"? Which they evidently have NOT.
Edge conditions aren't just for show, they're a standard test in any self-respecting test suite. If they have such grievous consequences to something so mind-stunningling simple to prevent, what the fuck else have they left in their code waiting to bite the helpless Apple iConsumer?
Except that most consumer devices will set the date and time themselves when first powered on OOB[1] by the grinning monkey that bought them. What they have at that point is, more often than not, more than 24 hours out from current.....
[1] A "must have" feature, unless you are prepared to hire a shitload of call centre staff who all have the patience of Job and an infinite supply of Ritalin within easy reach.
There's your problem right there.
We're talking about an OS that didn't apply saturating maths to the timezone subtraction (or, at least, bounds check it before blindly knocking off X hours) so what is the confidence that the NTP client is any good?
Also - why is this bricking iOS? Shouldn't it just think the date is 2106? Or are they still using signed integers for the date (and choking on negative dates - another bounds check fail)? Because, you know, 2038 is soooooo far away that it can be ignored for another two decades.
Testing is a thankless task. It's dull, it's repetitive, and it's not as glamorous as coding. So it isn't surprising that bugs like this sneak through in anyone's software (Apple's, Microsoft's, Google's, yours, mine)
It needn't be this way though. Automated testing, with intelligently designed scripts, can take care of all the boring repetitive tasks of ensuring that every function works the way that it is supposed to and regression testing. Those tests can be left running every night.
This frees up a lot of human tester time, not for redundancy (before all the accountants get excited) but to do the vital, interesting, and often overlooked task of what I like to think of as vandalism.
Vandalism is interesting testing because it's devious. It's imaginative. It doesn't concern itself with whether the software works as designed (the automated testing and UAT will take care of that). All it does is try to smash the software, crash it, break it by any means. And once a good exploit has been found, of course, it gets added to the test automation suite - and the tester goes back to be deviously destructive again.
I imagine that most of the big software companies do this already - but perhaps they should do it more. And I might point out that before you snigger too much at the 'notorious wobbliness' of Apple software, bugs like this are everywhere. Yes. Even in your own preferred OS.
Testing is a thankless task. It's dull, it's repetitive, and it's not as glamorous as coding
What Testing needs is something like what CSI has done to Forensic Science.
Then again, better not
The last thing Software Testing needs is what CSI has done to the perception and expectation of Forensic Science, by Joe Public
There are a lot of bugs in "big software" that automatic regression testing should have found.
It also seems to be quite difficult to get good testers in general - it seems like many just want to follow The Procedure and do nothing else.
Which rather crushes the enthusiasm of the ones who don't.
It is difficult to think up ways of crapping on software when you think you've spent a while building it - always best to get someone who doesnt know what they are meant to be doing - I remember blowing up a piece of bulletproof code in 1983 or so that we were going to pay £1/4 million for because we forgot they were coming to demo it until the day before and had to scramble to get something together for them to demonstrate how good it was on our stuff.
I used to write automated scripts to wander around the code libraries and throw random shit at them and see what happened - this modern stuff can be a bit difficult to do that with but you can often add an interface type layer specifically for accepting random shit.
And always remember running in a debugger solves almost all code defects so make your live code launch itself in the debugger.
Spot-on. It is impossible to test for every eventuality, of course, but yes, add to the test-suite once found. This is like the Y2K problem in reverse. A few other things I remember causing glitches:
Errors in software calculating Daylight Saving correctly; Leap Year calculations in non-contentious leap-year cases where March 1st came a day early. Spreadsheets using a different epoch start point. I can imagine shed-loads of problems at the other end of the Unix epoch (in a mere 22 years time).
I've worked in QA at very large software companies, and the key is to treat QA as a first rate engineering task, not an afterthought.
That means not just hiring interns and programmers that weren't good enough for the dev team. You need experienced, talented programmers writing tests, but not the same programmers that wrote the code. Those programmers are the ones that never thought of the problematic conditions in the first place, it's unlikely they will think it them when they write the tests,
> You need experienced, talented programmers writing tests
Yes. But at most places I've worked you would also need to an "and cheap" to that list of qualities.
QA is a great place to not only cut personnel costs, but the testing period is a great place to steal schedule time from when the developers run late (again). Or so I'm informed by various MBAs.
"Testing is a thankless task. It's dull, it's repetitive, and it's not as glamorous as coding."
That's no excuse. It just means they are hiring the wrong people.
There's plenty of people who do "thankless" and "repetitive" jobs but who still take pride in doing the job properly and well. Not everyone wants to be a high flyer living on adrenalin, they just want a quiet life, enough money to be comfortable and maybe a decent holiday or two each year.
It's equivalent (probably related) to fight or flight response. Not only are people spread across the spectrum from one end to other but the world needs to operate that way.
At least most of the world that was allowed to buy Vaxen would have been on the same calendar by then.
http://www.skip.net/DEC/HP-OpenVMSsystems-Y2K-SPR.htm
Of course, the Russians came late to the party, but they were not able to use Vaxen, unless of course they built their own, or "laundered" them through various "allies" of the U.S.
I love the people trying to defend this one with "Well, we never thought anyone would do that? Why would anyone do that?"
I'm sorry, you give an end user the ability to enter a value into ANYTHING you fucking sanitize that value before saving it somewhere. Users are untrustworthy bastards who will deliberately break things!
I expect that there was code to sanitize the input. It's just that the person who wrote it didn't have an accurate mental model of what "time" meant. Checking that the _local_ (entered) time is within some range is not sufficient. Those of us old enough to have lived through the Y2K scare can probably remember the amount of utter horseshit "solutions" proposed by various pundits. Apologies for the flashbacks if you are one of us. Real (robust) programming requires both real programming chops _and_ domain knowledge. Sadly, many corporations try to minimize the connection between the two.
Time to review https://www.youtube.com/watch?v=-5wpm-gesOY
It's a tough job, but somebody has to do it. IIRC, the last Y2K patch for WinNT came out in something like November 1999. And if you want to get entangled if a scary set of cracker-barrel tales, look into whether 1900 was a leap year, and what that did to people moving spreadsheets with historical data between DOS and MacOS versions of Excell.
And to think my very first (paid) programming job was working on the "Date 74" project on a PDP-10 where all dates were going to roll over in 1974. Seems that TOPS-10 only allowed a 12-bit field for "days since 1962" in the file system.
It's fuzzy, but as I recall they stole some bits from some other field which allowed an extension to some time in the 1990s, by which time *surely* no one would still be using the system. Hah! It wasn't Compuserve's only problem, but it was one more nail in the coffin.
Sigh. I know what the Net is going to look like next week, masses of spam and fake iOS advice to "fix" something or allusions to "settings that Apple wants to keep secret", all hoping to con innocent end users into setting iOS devices to Jan 1st 1970.
It's not funny for those users and those who need to help them :(.
Wondering if it could have been added to 'thwart' against non-Apple third party repairs.
A sort of trip wire/boobytrap for iPhones / iPad that had their battery replaced and/or circuit board replaced or modified. By disconnecting the main battery and say leaving the circuit board without power (in a storage tray etc) for a while when powering up again, the i-device would probably reset the clock to 01/01/1970.
There seems more to this than meet the eye, may not be a coding 'mistake', but a sneeky move to force repairs to be carried out by Apple rather than a third party, by bricking the circuit board in such a set of circumstances, when a third party repaired the device.
This might be another one of those 'its a feature' to protect consumers again.
This post has been deleted by its author
The VodaZap pager that I still use for production support won't recognise years after 2014. It's currently displaying 02/13/96.
I guess they thought pagers would be long gone by now, a bit like all that software that got changed for AD2K with the cunning "if the two-digit year is less than 27 then it's the 21st century, else it's the 20th" trick. I'm sure it will all have been decommissioned by then...
It's almost certainly not a negative problem, and probably a zero problem. time_t is 64 bits on OSX, and most UNIX and UNIX-like systems are very happy with negative numbers. Or at least they are in the C libraries, unless it is some new-fangled nonsense they're using:
time_t t = -10;
printf("%zu\n", sizeof t);
printf("%s", ctime(&t));
Gives this in UTC land:
8
Wed Dec 31 23:59:50 1969
Hey now, negative numbers can be a real challenge for the professional code-righter. I mean, you use them and you get yet another negative number. Perhaps rather than constantly having to write code that can handle rare occurrences like negative numbers, we should just ban their use?