Posted on 06/25/2010 12:17:10 PM PDT by PugetSoundSoldier
Do you have a PIN code on your iPhone? Well, while that might protect you from someone making a call or fiddling with your apps, it doesnt prevent access to your data as long as the person doing the snooping around is using Ubuntu Lucid Lynx 10.04.
Security experts Bernd Marienfeldt and Jim Herbeck discovered something really interesting when they hooked up a non-jailbroken, fully up-to-date iPhone 3GS to a PC running Lucid Lynx
I uncovered a data protection vulnerability [9], which I could reproduce on 3 other non jail broken 3GS iPhones (MC 131B, MC132B) with different iPhone OS versions installed (3.1.3-7E18 modem firmware 05.12.01 and version 3.1.2 -7D11, modem 05.11.07) , all PIN code protected which means the vulnerability bypasses authentication for various data where people most likely rely on data protection through encryption and do not expect that authentication is not in place.
(Excerpt) Read more at zdnet.com ...
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 dramaticIn 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.
So I assume you'll admit you were in error, now? Maybe you'll finally get it?
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.
> ...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.
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.
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.
You can call me Puget, PugetSoundSoldier, PSS, or Dan, thank you.
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.
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.
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.
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.
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.
I agree completely, and am surprised I was only called a Mac-hater and liar a few times...;)
Yes, there are a couple of blatant beasts on this thread, each speaking with a thousand tongues of calumny.
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.
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.
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]
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.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.