Apple releases iOS 7.0.2 - swiftly squashing two lockscreen bugs

Filed Under: Apple, Featured, iOS, Vulnerability

Apple has shown an open pair of ears and a lively pair of heels in dealing with two lockscreen bugs that it introduced with iOS 7.

Well done, Cupertino!

(To all hardcore Apple fans reading this: that's not irony. I really mean it.)

The fruity company has just released iOS 7.0.2, fixing the following:

Apple isn't saying too much about the first hole, letting on neither how it came about nor what needed fixing.

But the company has been reasonably frank in revealing what caused the second vulnerability:

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.

There are three interesting issues buried in here, and it's probably worth glancing at all of them.

NULL dereferences

Firstly, translating into English, a NULL dereference, also known as a null pointer error, is caused by mismanagement of memory.

When you ask the operating system to reserve a block of memory for your program to use, it typically hands you back the actual memory address you've been given, as a numerical value.

If you use the wrong address things will usually break; the operating system may or may not notice, and may or may not be able to do something about it.

It's a common sort of bug to get the address wrong by a small amount - that's a buffer overflow, where you overshoot or undershoot, possibly only by a single byte.

It's also a common sort of bug to access some utterly improbable memory address, by completely messing up the pointer variable where the address is stored.

→ A stored address is known as a pointer, because it points at a memory location. That is about as close to "literary" as programming terminology gets.

And it's also surprisingly common to try to access memory location zero, because in any operating system that takes security seriously, program variables that haven't yet been initialised automatically have the value zero.

That's a consistent way of making sure that uninitialised variables don't contain data left over in memory from before.

A memory address, or pointer, that has the value zero is a NULL pointer, and any attempt to use it is a NULL dereference.

Most operating systems, therefore, deliberately ensure that memory address zero is off limits to all programs, and always trigger an error if anyone tries to access it.

This handily and automatically catches all null pointer errors, as happened here.

Of course, 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 any program that dereferences a null pointer.

Race conditions

Secondly, the interaction between the restarting lockscreen and the call dialling software is what's known as a race condition.

There's a point at which the call dialler checks the state of the lockscreen.

If the restarting lockscreen wins the race, and fires up before the dialler gets there, everything works fine; if the dialler wins the race, the lockscreen can't tell the dialler what it needs to know.

Race conditions can be very hard to debug because they often occur only under unusual or contrived circumstances, as happened here.

(In this case, you can argue that Apple should make other software wait while the lockscreen is restarting, because of the key security function it performs.)

Failing open

Thirdly, the fact that the dialler assumes the best if it can't query the lock screen status is a fail open situation.

Fail open can be desirable and correct, even if some aspects of security are reduced: that's why electrically-operated security doors are typically held locked shut by the presence of power, so a power failure will release the lock and ensure the doors can be opened to let you escape.

(In this case, 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.)

What to do?

You don't need to know anything that I just told you about pointers, races and failure modes.

Just apply this patch.

Don't listen to what the hardcore Apple fans might have said, in commenting on our earlier articles, about these not really being bugs "because all you have to do is not lose your phone."

A locked phone should be locked.

, , , , , ,

You might like

7 Responses to Apple releases iOS 7.0.2 - swiftly squashing two lockscreen bugs

  1. It still doesn't matter though, because you shouldn't lose your phone. You'd guard your credit card like it's valuable. Do the same with your phone! I've seen so many people place their phones on tables and the like where they cn be easily and quickly taken by a passing thief.

  2. Brad · 203 days ago

    It does matter and it's absurd to say something like "don't lose X valuable" - losses aren't intentional! The risk of them being lost or compromised can be mitigated but in life unexpected things happen. Paul is absolutely right - a locked phone should be locked.

    I am a long time loyal Apple customer but it seems to me that - and I feared this - since Jobs' passing they're taking their eye off the ball. It occurs to me they aren't giving things the kind of attention to detail and thoroughness that was the hallmark of Jobs and one of the main reasons I like Apple and their products. The Maps fiasco, iOS 7 issues, etc have all occurred under the leadership of Mr Cook. Everyone makes mistakes, even multinational corporations, but these are things that Apple wouldn't historically allow to come to pass.

    I don't recall ever having to read an open letter apologising for failure by Steve Jobs. I'm not putting him on a pedestal, mind you, I'm just mindful of the fact that the attentiveness, precision and reputation of the company is dwindling slowly.

    Hopefully they regain their focus.

    Good read Paul, thanks.

  3. Tim · 203 days ago

    I'm not a 'hardcore' Apple fan. I just have one at home because I got tired of doing IT support for myself at home.

    I've not yet had the chance to double-click on an Apple trojan and set it up so that Sophos Anti-Virus for the Mac can get rid of it for me.

    It's a good policy whatever OS you run to install updates and patches, but you'd much rather report on people driving onto runways because they don't use their common sense, or putting their iPhones in a bucket because they didn't use their common sense.

  4. Jack Wilborn · 203 days ago

    A point about NULL pointer reference is that when you allocate memory, you are usually returned a NULL value upon failure. If you don't check for success, you lose.

    Jack

    • Paul Ducklin · 202 days ago

      Good point. Another likely way to get zero in a pointer variable!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog