I'm struggling to think of a good reason (except within a couple days of New Year's) other than it makes installing apps with dodgy developer certificates more difficult...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
New Version of 'January 1, 1970 Bug' Can Brick Pre-iOS 9.3.1 Devices Over Compromised Wi-Fi Networks
- Thread starter MacRumors
- Start date
- Sort by reaction score
I dealt with Apple over 10 years ago with laptops where the battery drains, the laptop recovers power and the date/time is set in a similar way....since the date was so far back the keychain would not work so Wifi settings would not be applied for NTP to set the date/time correctly....yet, over the years...this is STILL an issue....amazing.
That's eggshell security, which only keeps out the weak hackers, leaving you vulnerable to the high intensity hackers while giving you a false sense of security. The problem is that ntp shouldn't be setting the time to before the device existed and/or the device should properly handle any time that can be set. If you think the solution is security certificates, then you don't understand the problems of security certificates.
It shouldn't have happened in the first place. How hard is that to understand.
It's basic common sense programming to check inputs for validity before you use them, especially when it involves critical things and/or unreliable sources.
[doublepost=1460648516][/doublepost]
If the AP is encrypted and can be accessed by anyone with the password, and that password is given out freely (lots of places do it that way), you can still set up a second network and spoof denials to the clients connecting to the original MAC address forcing people to connect through your "hack" AP.
Unencrypted wifi is not the fix or problem here. (also your ad-hoc example is completely different as that works differently)
I have a wifi AP at home that is set up with the same credentials as the office AP and my home-work LAN is connected (over IPSEC link) to my work-work LAN so I even get DHCP'd the same address at home for my work devices and it's just like I'm at the office (great for work-at-home types).
Last edited by a moderator:
Bugs happen, why is that reality so hard to accept for anyone? Yes, they shouldn't happen, but it doesn't change the reality that they do happen, no matter what company or software or whatnot.
Last edited by a moderator:
Only a pure and simple idiot would forget to check an input for validity on the platform. Period, end of sentence.
Attitudes like yours are what cause these things. "no one's perfect so I don't have to try". That attitude is the same of the block heads that think "all the kids should get a trophy".
No, perfection in humanity is not possible. Perfection in code? Very much possible.
Protip: if you have a Mac and sync both to the cloud, anything you clean out of the list on your Mac will be removed from the phone more or less instantly.
[doublepost=1460650105][/doublepost]
And, speaking as someone who worked in the computer security field in a previous job, and has worked in the software industry for decades, I can see clearly that neither your knowledge of computers nor your high-schooler's determination that you know more than anyone else about subjects you know next to nothing about has changed since you took that class.
Seems like a very simplistic and theoretical approach to coding and software development is being applied there. In practice things are not as they are in theory. And then more is being read into what was said when nothing of that sort was mentioned or implied.
It's also interesting how humanity and code are compared and contrasted as well, completely overlooking the link that humans are the ones that code. All that can certainly be ignored for convenience, or to try to make some point, but it doesn't change basic reality.
http://www.openbsd.org/55.html
They solved it in the OS and all of the base utilities for OpenBSD about 2 years ago. Feel free to copy. You're welcome.
Maybe someone can test this, but the article says:
It SHOULD require a certificate to match, but it looks like it doesn't.
That code is only good while we're in the year 2016.
Well no, because if you set the year to 2017 or more, then currentYear > 2016, so nothing will happen, and it's all fine. This code only does anything if you set the year to anything less than 2016, at which point it will just set it to 2016. So it just prevents you from setting the year back to anything before 2016. I thought of everything, I specialize in time travel for a reason!
All you've done is made 2016 the earliest possible year the user can choose. That's no different to Apple making 2001 the earliest possible year in the iOS 9.3 release. What have you really achieved? I thought you wanted to stop users from being able to select an earlier year altogether.
A better solution would be
Code:
actualYear = [some method to get actual year]
if (currentYear < actualYear) {
currentYear = actualYear;
}Now it's impossible for users to set their device to an earlier year.
Not much good for the users travelling from Australia to the US on New Year's Eve. There's always one.All you've done is made 2016 the earliest possible year the user can choose. That's no different to Apple making 2001 the earliest possible year in the iOS 9.3 release. What have you really achieved? I thought you wanted to stop users from being able to select an earlier year altogether.
A better solution would be
Code:actualYear = [some method to get actual year] if (currentYear < actualYear) { currentYear = actualYear; }
Now it's impossible for users to set their device to an earlier year.
That attwifi connection is likely unsecured though isn't it?
This is a question that's always bothered me with some of these claims about these wifi 'pineapple' devices, so I've tried to do a little research but I'm pretty much a wifi novice.
Yeah, it's unsecured. I don't know about WPA personal, but WPA enterprise does have certificate checking. I don't know if the standard has such a thing, but it could've had a certificate check for unsecured networks. I guess either Apple or those controlling the wifi standards didn't want to add identity checking because that would force users to hit "accept" every time they joined a different network with the same name, and users would blindly say yes anyway. I wonder if AT&T could've had a shared certificate for all their attwifi networks that devices could've been forced to check.
BTW, I don't really know anything about how wifi is actually implemented. This stuff is impossible to Google without getting people using Windows XP asking what wifi is.
Edit: Googling around, I found another attack on iOS that exploited this: http://www.macworld.com/article/291...ic-wi-fi-connections-and-a-security-flaw.html
Last edited:
If perfection in humanity is not possible, then perfection in code (or anything else created by humanity) is also not possible. Something imperfect cannot create something perfect. (And something perfect could not create something imperfect.)
The thing you miss is the fact that you can only do so many things and only so many responses are "valid" in any case. It's especially not hard with an integer and checking that it be some sane value before using it.
Last edited:
Seems like you are overlooking all the dependencies and interconnectivity that happens in coding when it comes to something as complex and large as an OS. Still, perhaps the even bigger piece that you actually yourself bring up and then just simply ignore is the human factor. No one is really saying that having issues is somehow good or right or anything like that, just that the reality is that issues (whether they are complex or simple) can happen, have happened, and will happen. The grasping certainly seems to be at the foundation in all of that.The thing you miss is the fact that you can only do so many things and only so many responses are "valid" in any case. It's especially not hard with an integer and checking that it be some sane value before using it.
It's a hard concept for people who have no experience to grasp I guess...
indeed
Last edited:
Right. The bigger security issue here is that known networks can be spoofed and joined automatically, which opens one up to this and a lot of other security problems. If iOS had more options for remembering (or forgetting) wi-fi networks, most people would never be exposed to these types of threats. The options we have now to avoid this are not very practical - we either have to forget all networks and passwords (reset networks) or ask to join EVERY time you connect to any wi-fi, neither of which most people want to have to do.
There's nothing difficult with "solving" the problem. The real issue is to find all the places where time is stored in 32-bit.
If it was so incredibly easy, how come we are still ridden with time_t 0? Even if time_t is in 256-bit, there might still be uses that rely on time_t being 32-bit. When it goes above that, **** will happen but it will not show until it actually wraps around.