It turns out that Apple didn’t fix future problems of this sort proactively, because the just-announced iOS 7.0.3 closes three more locked-phone holes.
The three bugs this time deal with similar problems to those patched in 7.0.2:
- Another flaw in the emergency call feature, where hitting the call button at a carefully-planned moment lets you call any number, not just 911 or your local equivalent.
- A passcode lockout bypass, so that crackers can continue trying passcodes even after the phone decides they’ve had too many goes and locks them out.
- Access to the Contacts pane even when the phone is locked.
Interestingly, the bug fix for the emergency call problem is described as follows:
A NULL dereference existed in the lock screen which would cause it to restart if the emergency call button was tapped while a notification was being swiped and while the camera pane was partly visible. While the lock screen was restarting, the call dialer could not get the lock screen state and assumed the device was unlocked, and so allowed non-emergency numbers to be dialed. This issue was addressed by avoiding the NULL dereference.
If you are experiencing déjà vu, you should be, because you’ve seen this before, in the iOS 7.0.2 security notes:
A NULL dereference existed in the lock screen which would cause it to restart if the emergency call button was tapped repeatedly. While the lock screen was restarting, the call dialer could not get the lock screen state and assumed the device was unlocked, and so allowed non-emergency numbers to be dialed. This issue was addressed by avoiding the NULL dereference.
As we explained last time, NULL pointers (references to memory addresses) can’t be dereferenced – that makes no programmatic sense, since a NULL pointer is, as a matter of definition, one that doesn’t point anywhere.
When a progam tries to dereference NULL, it’s almost impossible to determine what the programmer intended – who knows what memory location was supposed to be used instead? – so the operating system has little choice but to terminate it.
→ A NULL pointer usually means an uninitialised variable, or a memory allocation error, denoted with the special value NULL, that has been ignored. In the former case, you’re trying to use memory without even trying to allocate it first; in the second, you’re trying to use memory that you requested but never actually received.
So, correcting the NULL dereference wasn’t the wrong thing for Apple to do, but it clearly wasn’t enough to deal generically with this sort of lockscreen flaw.
When iOS 7.0.2 came out, we offered the following observations:
- You can argue that Apple should make other software wait while the lockscreen is restarting, because of the key security function it performs.
- You can argue that Apple should code things to fail closed: if the lockscreen software doesn’t know or can’t tell you whether the phone is locked or unlocked, treat it as locked, for security’s sake.
Of course, that’s easier said than done, because mobile phone regulators pretty much mandate some sort of bypass mechanism in a phone’s lockscreen.
That’s so emergency calls can be made any time the phone is powered up and in contact with the network. (You can even make 911 calls without a SIM card, for example).
That makes it hard to implement a lock screen “in reverse” – in other words, so that the phone is only unlocked when the lockscreen software is running, not the other way around – and it probably explains Apple’s reluctance to make big changes in the way the lock screen works for what is just a point release of iOS.
The flip side of that, if it’s true, is that iOS 7.0.3 ought to be uncontroversial, due to making only modest code changes inside the operating system.
In other words, if you are keen on security, you may as well make sure you grab this update as soon as you can, if your phone hasn’t done it for you already.