Ubuntu Lucid Lynx 10.04 can read your iPhone's secrets

ZDNet ^ | May 27, 2010 | Adrian Kingsley-Hughes

[dayglored]

> Looks like many of the macbots will be upset with your finding. If this is in fact a bug and not a feature it means the iPhone has been exploited in the wild. If it was a feature it would be a weak feature by not putting security first; however, at least then it was a conscience decision to do so. As a bug it means the underlying OS wasn’t inherently secure as many have claimed in the past.

First, will you please stop with the juvenile "macbots" crap? This is a serious discussion. Thanks.

Now, it appears to me that:

1. The iPhone allows its media partition to be mounted on a host operating system without challenge.

2. According to the site here:

UPDATE 02/06/10: It appears the issue only applies if you switch the device off during an “unlocked” state (thus you entered the passcode already and see the icons) but not if you power it down while it requests you to enter a passcode making this whole mess less dramatic…

In other words, while the report is true, there's a required condition -- that you unlock the iPhone first by entering the PIN, then power it down, then attach it to the host computer, then power the iPhone back up. It stays in the prior-unlocked state.

So it appears to me that the "bug" is that the iPhone does not automatically lock itself when you power it down. This could indeed be intended as a "feature", but I agree with you that it's not a great feature, security-wise. I would vote to change this behavior, no doubt at all.

So it's looking like this is not an OS issue, but rather a problem in the definition of the locking feature with regard to passing through a power-cycle. If so, then it ought to be easy for Apple to address.

It is not an "exploit in the wild". It's a poorly implemented feature that we agree ought to be changed.

[PugetSoundSoldier]

Sorry, you're wrong. There are Android platform encryption tools, which is a full 256 bit AES encryption, the strongest out there. And there are plenty of remote-wipe applications as well.

So I assume you'll admit you were in error, now? Maybe you'll finally get it?

[RightOnTheLeftCoast]

None of those three links even mention Exchange. Do you even know what that is?

I am not claiming that it is not possible to encrypt your Android device. I am, however, here to inform you that device-level (that is, hardware) encryption is commonly necessary for remote connections in corporate Exchange server setups. Blackberry devices do hardware encryption; so does iPhone 3GS and 4. As far as I can tell, no Android device meets this standard.

[RightOnTheLeftCoast]

"It is not an "exploit in the wild". It's a poorly implemented feature that we agree ought to be changed."

And this brings my conversation full circle, as I posted yesterday, on another thread, that this appears to have been fixed in iOS 4: Specifically, CVE-ID: CVE-2010-1775 in http://support.apple.com/kb/HT4225:

Description: A device with a passcode set may only be paired with a computer if the device is unlocked. A race condition permits pairing for a short period after the initial boot, if the device was unlocked before powering down. If the device was shut down from a locked state, this issue does not occur. This issue is addressed through improved checking for the locked state.

At the time, Pug objected that that isn't the issue as reported in one of those hysterical posts about Ubuntu. I shrugged and admitted he might be right. But it's looking more like it is indeed the issue, and has indeed been fixed in the latest OS. In any case, the notion that the entire file system is exposed for whooshing over USB "in 40 seconds" looks to be not true. It certainly doesn't strike me as the huge stop-the-presses issue Pug has made it out to be. Lose physical possession of a device, it's bad news one way or the other. That's why Blackberry and Apple offer remote-wipe capabilities. Let's put it this way: I'd much rather lose my iPhone than my wallet.

[dayglored]

Fixing this behavior in 4.0 is great, but my first-gen iPod Touch won't support 4.0. :( Oh well, it's just an iPod, not an iPhone anyway.

> ...whooshing over USB "in 40 seconds"

That was determined to be a computational mistake. PugetSoundSoldier fessed-up to a math error, and that is a closed issue. It's about a factor of 20, meaning the 40 seconds is actually more like 15 minutes, which makes a lot more sense.

[PugetSoundSoldier]

None of those three links even mention Exchange. Do you even know what that is?

Oh, I definitely do! Apparently you're a bit lacking in knowledge. Android has supported Microsoft Exchange since 2008. What's your problem? Are you just being obtuse on purpose?

I am, however, here to inform you that device-level (that is, hardware) encryption is commonly necessary for remote connections in corporate Exchange server setups. Blackberry devices do hardware encryption; so does iPhone 3GS and 4. As far as I can tell, no Android device meets this standard. As far as I can tell, no Android device meets this standard.

Device level means "hardware based"? Yet another term you're redefining or making up? Businesses allow laptops WITHOUT hardware encryption to connect to Exchange all the time; you need to implement an SSH tunnel, provide for local encryption as needed (hardware or software) and you can do that with Android. And many times you need to support remote wipe and password security policies - which those apps I linked supplied.

Here's another app that works.

So yes, Android works fine with corporate situations. But don't just take my word for it (you won't); Motorola can set you straight.

[itsahoot]

What's not to appreciate about all that inforamation?

I have heard these stories for years, ever since the Apple II days, and yet I have never had any data stolen, go figure.

I get all the real info need from MacSurfer, these threads are only provided as baiting sessions, for the Apple HyperCritics.

Just let it go, we will be OK, without all the help that we don't need.

[PugetSoundSoldier]

Pug objected

You can call me Puget, PugetSoundSoldier, PSS, or Dan, thank you.

[itsahoot]

Just because a security hole does not apply to your specific situation does not mean it is a non-issue to everyone else.

Then you should post your FUD to sites that have millions of users and generate millions of responses, not some FR thread that will generate at most a hundred individual responses.

And old adage; No matter how pretty the can, if the dog won't eat it, it won't sell.

[PugetSoundSoldier]

FUD? This was a serious concern for many people, and until it’s resolved it should remain so. If you wish to keep your head in the sand, then you can stay out of the threads.

[for-q-clinton]

I have one guy saying it’s a bug another saying it’s a feature. We’ll have to wait and see which is accurate.

[for-q-clinton]

So now you’re saying swordmaker shouldn’t post Mac info here because there isn’t enough viewers?

I don’t think he’ll appreciate that.

[dayglored]

> I have one guy saying it’s a bug another saying it’s a feature. We’ll have to wait and see which is accurate.

You'll wait a LONG time. Here's my take. Either it was intentional on Apple's design team's part, or it was unintentional.

** If it was intentional, then it was a "poorly implemented feature". Probably they wanted to have the device maintain the last-set-state by the user, and they decided to do so across a power-cycle. There's a possible justification, but I consider it weak. I would vote to have the device lock itself on power-cycle. So did Apple -- since they changed the behavior in 4.0.

** If it was unintentional -- that is, they intended to have it lock across a power-cycle, and failed to code that behavior correctly -- then it is a "bug". If so, then they corrected it in 4.0.

I doubt strongly that Apple would go out of their way to say what their design team was thinking. Instead, they simply changed the behavior. That change, by itself, does not indicate anything about their original intention, but it does say that they agree that it wasn't good the way it was.

Therefore, since Apple's code is proprietary, not open source, we won't ever learn whether it was a bug or a poorly implemented feature.

In my humble opinion, the issue is closed. My thanks to Puget for posting the thread, since it was fairly interesting and made for some lively discussion.

[PugetSoundSoldier]

In my humble opinion, the issue is closed. My thanks to Puget for posting the thread, since it was fairly interesting and made for some lively discussion.

I agree completely, and am surprised I was only called a Mac-hater and liar a few times...;)

[stripes1776]

Yes, there are a couple of blatant beasts on this thread, each speaking with a thousand tongues of calumny.

[Swordmaker]

I have the proof...show me where you CAN do that...the mere fact that you can’t is proof enough.

No, I'm just asking you for proof that someone somewhere CAN'T get in. Prove the negative. You can't know for certain, for-q-clinton. You are merely asserting it. Unless the data in the phone is encrypted (and likely even then) there are ways to get at the data.

[Swordmaker]

Does that somehow invalidate the security hole in iPhone? Is the article in error?

I did not say it did... My only point is that asserting that A is safe because I think it is, but I haven't tested it in every possible way that it could be compromised, is not proof that A is safe. This iPhone vulnerability is just such an example. Someone found that if you did actions XYZ on the iPhone, you got this result. Instead of quietly reporting it to Apple through channels (I may be wrong on this) so it can be quietly fixed before it can be exploited by criminals, apparently they are gleefully trumpeting it far and wide.

[RightOnTheLeftCoast]

"Android has supported Microsoft Exchange since 2008. What's your problem? Are you just being obtuse on purpose?"

I wish you'd learn to provide a link or two to at least attempt to support your bogus claims. The Exchange "support" you mention was very limited in 2008 and still, near as I can tell, doesn't include encryption baked into the mix. I rely on published accounts such as this one from CNet from late last year:

"[Android's] lack of real encryption is a serious concern. The security measures that are built into Android 2.0 are limited at best. Yes, end users can set up finger-swipe passwords for when their screens time out or after the handset reboots. And yes, Droid lets you secure your information with an alphanumeric password.

"Unfortunately, that's about it. IT professionals can't define security policies, perform a remote wipe, or remotely provision handsets, which means that your IT manager would essentially have to physically touch every device to set it up. And if you lose your handset, your data might be as good as compromised."

Perhaps the situation has improved with post-2.0 versions of Android, but from your links it seems not, and costly and confusing arrays of third-party software are needed to implement even rudimentary software encryption. Because that's all you'll get, and as I've been saying, that's usually not enough. For example there's things like this: "Android hardware also lacks support for hardware encryption, making the devices ineligible for support by the default security policy of Exchange Server."


Which is what I've been trying to inform you. See, we latte-sipping and probably gay Macbots have been there before. Apple introduced a perfectly operable software-encryption-based Exchange capability in iPhone OS 3, then had to disable it for the older iPhone 3G, which lacked the necessary hardware encryption to meet default Exchange security policies as commonly configured.

Now it might be that one of the very latest Android phones running the very latest Android OS is finally equipped to perform hardware encryption, bringing it up to the level of capability of the last-generation iPhone 3GS. But if so, that doesn't exactly leap from the pages of those links you provided. Which is another problem with Android: it's freaking chaos out there.

Your apologies are accepted.

[RightOnTheLeftCoast]

Oh, and by the way, I'd hope Motorola might set you straight too. Referring to your link and noting a little click-thingie for what to do if your Droid doesn't work with the Exchange Server, I dug a little deeper. Sure enough, if your Exchange Server device policies require encryption (and, dear me, isn't that what I've been talking about all along?), there are instructions to... get ready... just turn it off! How about that.

Have a cigar. [>boom<]

----

DROID - Exchange Email Troubleshooting

If you are able to successfully connect an Exchange account on your phone, but your email and contacts are not syncing with your device, your company may have a security policy that prevents syncing. 

At launch, Motorola DROID's native exchange solution doesn't support password security policy or remote wipe.

If your company's exchange server has been setup to ONLY allow devices that support password security policy, your IT administrator will need to customize some of the settings on the Exchange server for your Motorola DROID to successfully sync.

What options do I have if my company has password security policy on their exchange server?

Option 1 - Instructions for configuring your Exchange Settings

The following solution describes the options that your IT admin can take to adjust the password security policies on your Exchange server to allow DROID connectivity. The available options depend on whether you have Microsoft® Exchange 2003 Server or  Microsoft® Exchange 2007 Server. Mobile Email Sync can not be set-up on a Microsoft® Exchange 2000 Server.

Remember that you can protect the data on your device by enabling "gesture" lock in Settings => Location & security menu.

Option 2 - While we do not endorse or guarantee these solutions, or provide support for them, some owners have reported success using a 3rd party Android Application like "Touchdown Exchange".  You can search the Android Market for 3rd party applications that are available that will enable you to provision Exchange email with force password security policies.

Exchange 2003 SP2 Instructions
    
1.     Launch Microsoft Exchange System Manager:




2.     Change Mobile Service Properties:




3.     Select device security




4.     Enable "Allow access to devices that do not fully support password settings." Turning on this setting will allow devices like the Motorola DROID to connect to your Exchange server. This will not change any requirements for devices that do fully support Exchange security policy - they will continue to require password access. [snip]

[Swordmaker]

I see you pulled the usual Swordmaker trick of putting words in my mouth to suddenly qualify my statement so that you can try to prove your point; I never said what size iPhone, now did I?

But let's just take a look anyway... With a transfer rate of 480 Mbps, you could copy 8 GB in about 20 seconds, and 16 GB in about 40 seconds.

No, Puget, I agree, you did not say what size iPhone... but there was no need.

And, I would challenge your claims... 8 GIGABYTES in 20 seconds??? 16 GIGABYTES in 40 seconds? Over a USB cable? No way! You claim is Bull Sh!t on ANY SIZE iPhone!

You say you've seen "...close to that sustained rate with Ubuntu and Win 7..." Then, if you are implying that mythical 8GIGABYTES in 20 seconds, Puget, I have to call that a lie.

Your own link and you state that the USB 2.0 transfer rate is 480 Megabits per second... divide that by a factor of ~12 (you need word start and stop bits) to get MegaBYTES per second... Theoretically, and Practically, we are looking at ~40 MegaBytes per second of actual data... but that's just practically, given ideal conditions and connections.

Consider this from your own link, AGAIN:

4. How fast is USB 2.0?
USB 2.0 has a raw data rate at 480Mbps, and it is rated 40 times faster than its predecessor interface, USB 1.1, which tops at 12Mbps. Originally, USB 2.0 was intended to go only as fast as 240Mbps, but in October 1999, USB 2.0 Promoter Group pumped up the speed to 480Mbps.

As far as we know, effective rate reaches at 40MBps or 320Mbps for bulk transfer on a USB 2.0 hard drive with no one else is sharing the bus. Flash Drives seem to be catching up too with the some hitting 30MB/s milestone. For all we know, USB interface could become become the bottleneck for flash drives as early as 2008.

Additional notes from Alex Esquenet - our engineer friend based in Belgium: "A fast usb host can achieve 40 MBytes/sec. The theorical 60 MB/sec cannot be achieved, because of the margin taken between the sof's (125 us), so if a packet cannot take place before the sof, the packet will be rescheduled after the next sof. On top of that, all the USB transactions are handled by software on the PC. For instance, a USB host on a PCI bus will send or receive the data via the PCI bus; the stack will prepare the next data in memory and receive interrupt from the host."

Let's analyze this further... the authoritative source says that the effective rate is 40MegaBytes per second... but let's go with the theoretical maximum of 60Megabytes per second. How long would it take to transfer just 1 GigaByte of data over a USB 2.0 cable??? About 17 seconds. To get your 8 GigaBytes, it would take over two minutes... at that unachievable theoretical maximum transfer rate. In the real world, it would take about five minutes; for a 16 GigaByte unit: 10 minutes; for a 32 GigaByte, 20 minutes or so... of course, assuming they were full to capacity and you were copying everything including pictures of old Aunt Cassie's cat.

The more you talk, the less I know you know... and the less I think you are an engineer in software or hardware for computers.