Comments

Otto • November 9, 2011 5:40 AM

Not really that surprising. They made the smart cover in such a way that the iPad knows when its shut or not and has special locking/unlocking behaviors based on that. an unexpected consequence of their behavior mechanism doesn’t account for the power-off screen, which resides in a different part of the system and is accessed in a different way, overriding other parts of the system.

Integration testing among different subsystems can be tricky like that.

Dom De Vitto • November 9, 2011 6:24 AM

I’ve pretty sure regression testing doesn’t cover new features 😉

The real problem here is that the lockscreen is interrupted by power-down, rather than it being invoked by the lockscreen s/w.

It’s exactly the same core problem that created the lockscreen bypass by selecting emergency call.

Basically, it’s a silly race condition that should be designed-out, rather than kludged-out catching corner cases….

I’m sure there is a Siri bug around the corner too….

Clive Robinson • November 9, 2011 6:49 AM

It certainly sounds like a “features upgrade race condition” Android in earlier versions has a similar problem with slide out keypads and incorectly written keypad drivers.

The problem with adding “features” that either have or effect core functionality is ensuring they don’t override existing core functionality in some way.

A classic problem with battery powered devices is power saving timers, instead of having just one core system you end up with several timers all that time out in different times for various reasons (especialy when not built in the core time algorithms but in apps on multitasking systems). They all fire off at different times and in some when the hiebernate or background signal comes along they stop their timers in others they reset them to either zero time etc.

For those realy old enough you could see this in some early realtime systems, and the solution back then as it is now is to have a proper system wide time/event subsystem built into the core but this can realy chew through CPU cycles esspecialy with (less than; “smart” apps developers, and can have security implications (as it runs in ring zero)…

Zingus • November 9, 2011 7:06 AM

Everybody says it’s normal. I say it is not: my guess is they had to jump though loops to override the locking system.

To me this unsecure flaw looks like it was commanded from above by lunatic management with a vision.

Greg • November 9, 2011 7:56 AM

Isn’t this the hack-around the Windows 95 screen-saver password where you jumped from the login dialog, to help, to print, and then clicked cancel…

RandomPundit • November 9, 2011 8:00 AM

You guys do realize that this is patched in iOS 5.01 which has been in beta since Nov 2nd, right? This is not really new news.

An interesting bug to be sure.
One worth exaggerating the impact of a device you could sooner steal anyway?

Not really.

Clive Robinson • November 9, 2011 8:55 AM

@ RandomPundit,

“You guys do realize that this is patched in iOS 5.0 which has been in beta since Nov 2nd, right? This is not really new news”

I guess you’ve not been around this blog for very long.

Although there are “news items” from time to time the blog is not about news, but security and it’s underlying causes (and on the odd occasion this blog also generates “news” due to journalists “lurking” and picking up titbits for their op-eds etc).

As you note it is “An interesting bug to be sure”, the reason for this is not however it’s “news worthiness to Apple Users” but the underlying reason for which the bug occured.

The reason for this is best sumed up by the old “saw” of “Those who do not learn from history are condemned to re-live it endlessly”.

The important words being “learn from history”, some people are old enough to remember the Comet Jet aircraft falling unexpectedly out of the sky, it was highly news worthy at the time. But of more importance was what was learned from this and, how it did improve and continues to improve aircraft safety.

Remember for some languages there are not seperate words for safety and security and there is good reason for this. Thus with a little thought. you will probably conclude that in the majority of cases “security” and “safety” are interchangable both in diagnose and resolution methods employed.

So security improves when the generalised and sometimes specific causes of a newsworthy incident are analysed and disseminated in the correct way which usually involves due reflection.

JS • November 9, 2011 9:11 AM

I wonder if this “exploit” works on devices with an enterprise profile loaded. If it did, it would be one more ding against the suitability of the iPad 2 in a corporate environment.

Other companies making secure tablets (c.f. BlackBerry Playbook) have worked much harder to ensure that their devices are not susceptible to bypasses like this.

Random Pundit • November 9, 2011 9:40 AM

@Clive Robinson, I hear you but I’ve got to stand by what I said.

It’s an interesting bug and one that I think is worth discussing, but nothing more.

Most importantly to me, it points out that Apple’s locking process is not immutable. ( I don’t mean that in the theoretical “Is any locking system pick proof”, but in a more practical sense )

Assuming the bug was indeed exposed by some sort of race condition, rather than the bug being in the locking mechanism itself.

But this is just silly speculation until someone on the inside provides more information.

When all is boiled down, it’s a novel circumvention of a weak control.
Minor enough that Apple themselves aren’t bothering to promote the patch schedule to stop it. And I can’t say I disagree.

RH • November 9, 2011 10:01 AM

@Clive: nice argument, as always =)

I’ve always been frustrated by Apple’s approach to security. They had none before OSX, when they inherited BSD and figured they were totally safe. Their approach to development is “find cool new feature, add it, test to see if it is secure” rather than “find cool new feature, figure out how to do it securely, add it, test it.”

I hear of more and more Apple bugs every day, and fewer Microsoft bugs. I can’t tell if that’s Apple getting more market share, MS trying to get their act together, or maybe just everyone’s flocking away from that unusable pile of dung called Office 2007 (and beyond) and still not trusting the giant after Vista’s failure (its amazing how many security issues go away when you stop using systems that embed programs in documents).

Joe • November 9, 2011 9:10 PM

I’ve disabled my smart cover but the bypass only allows you to access the open application. If you lock on the home screen then you can’t launch applications (but it looks unlocked). It’s no big problem but the security aspects are a worry.

Popo • November 9, 2011 9:34 PM

Duh! I expect this from a “Smart” cover. Next time someone complains about the inflated accessory price, laugh and unlock their iPads.

alfora • November 10, 2011 1:53 PM

@AreYouR00t: The reason for this is that this bug was fixed in iOS 5.0.1

From the release notes:

Passcode Lock
Available for: iOS 4.3 through 5.0 for iPad 2
Impact: A person with physical access to a locked iPad 2 may be able
to access some of the user’s data
Description: When a Smart Cover is opened while iPad 2 is confirming
power off in the locked state, the iPad does not request a passcode.
This allows some access to the iPad, but data protected by Data
Protection is inaccessible and apps cannot be launched.
CVE-ID
CVE-2011-3440

Jason T. Miller • November 10, 2011 4:24 PM

@RH: Microsoft security has been improving by painful, expensive, time-consuming, and (this is important) highly publicized changes to their internal product design and development practices.

In contrast to older releases of Windows, iOS, has a very good practical security record, even now that it’s quite widely deployed, so it’d be difficult to make a business case inside Apple to “throw out the baby with the bathwater” by overhauling their design and development practices in the name of “security,” especially publicly.

Also important to note is the fact that Microsoft (and RIM) target “enterprise IT” applications where security requirements go far beyond “protection from user error and malware,” while Apple designs and markets products primarily for “personal use.”

Dirk Praet • November 16, 2011 10:08 AM

As Clive days, a classic example of writing a feature that doesn’t correctly hook into core functionality mechanisms.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.