iOS 7 Security Flaw Leaves Stored Email Attachments Unencrypted [Updated]

[OhHaiThere]

Yes in could be that in some cases where a user working at "mycompany.com" sends email to another person at mycompany.com and that the mail stays inside a company email server. But (1) this is a special case and (2) many times, maybe even most times that mail server is run by the company's ISP. Only the larger companies have their own in-house mail servers,most left someone like the ISP handle it.

So in the special case in internal emails where the company runs its own servers there is no exposure but in all other cases the PDF attachment is going to be stored many times at random unknown places all over the Internet.

Take a look at your own email. Look at the raw headers, but the smaller subset the mail reader shows. Look at the raw text files and see how many "Received By" header are in one of your typical emails. A half dozen such lines are not uncommon.

This is not a special case and those corporate/government servers are exactly where the information is most sensitive anyway. Nobody cares about the selfie your girlfriend sends you - well, besides you.

I wrote earlier that we had reported this issue to Apple over a year ago (privately), I chuckled reading the headline.

Love it how any time there's an issue with iDevice X, fanboys have every excuse in the world to make it seem inconsequential. Oh boy, if this were the case on another phone.... why we wouldn't hear the end of it.

 

[mattintoshmac]

Exaggerated FUD. So what.

 

[AppliedMicro]

This is not a special case and those corporate/government servers are exactly where the information is most sensitive anyway.

Exactly.

When I send an internal email from my company account, it's sent over a secured connection to my company's secured mail server, gets delivered to the user mailbox on this very server, and then picked up over a secured connection by my colleague's or boss's device.

It's never sent "in cleartext" over the internet.

 

[Tech198]

This security flaw only affects iPhone 4 and below, iPhone 4S, 5 & 5S running iOS 7.1.1 is ok since there is no JB (yet).

So i'm safe

So really as bad as it seems.... Just an over-bloat story...... Any one running 7.0.4 on their 5S, does not care about security anyway, or apps which they use are too old, not updated anymore.

 

[Swift]

This vulnerability is in e-mail

Unless you use an onion router or other hacker thing, when you send an e-mail, it is in the clear, not encrypted. That service used by Snowden? It sent encrypted, but it was totally unencrypted while on the servers.

This affects, according to Mr. iMore, only iPhone 4s, it requires physical possession of the phone with jailbreaking tools, and it requires that you do not use a complicated password or even a passcode. And then, they can't read the e-mail, but they can see the pictures you were mailing to grandma of the kids. We need to have clear-eyed conversations about privacy, not hysteria. It is a flaw. It affects a tiny percentage of the iPhone audience. It will be fixed, even though this is hardly exposing your Apple ID to charges or your secret existence to the world.

 

[sjinsjca]

I wonder if this vulnerability is present in OSX...

Different encryption techniques. OS X = whole disk encryption (FileVault 2). Not the case with iOS... there's an Apple tech note some place about it, but it's not whole-disk.

Update: see https://www.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf

From p. 7:

Architecture overview
Every time a file on the data partition is created, Data Protection creates a new 256-bit key (the “per-file” key) and gives it to the hardware AES engine, which uses the key to encrypt the file as it is written to flash memory using AES CBC mode. The initialization vector (IV) is the output of a linear feedback shift register (LFSR) calculated with the block offset into the file, encrypted with the SHA-1 hash of the per-file key.

The per-file key is wrapped with one of several class keys, depending on the circum- stances under which the file should be accessible. Like all other wrappings, this is performed using NIST AES key wrapping, per RFC 3394. The wrapped per-file key is stored in the file’s metadata.

When a file is opened, its metadata is decrypted with the file system key, revealing the wrapped per-file key and a notation on which class protects it. The per-file key is unwrapped with the class key, then supplied to the hardware AES engine, which decrypts the file as it is read from flash memory.

The metadata of all files in the file system are encrypted with a random key, which is created when iOS is first installed or when the device is wiped by a user. The file system key is stored in Effaceable Storage. Since it’s stored on the device, this key is not used to maintain the confidentiality of data; instead, it’s designed to be quickly erased on demand (by the user, with the “Erase all content and settings” option, or by a user or administrator issuing a remote wipe command from a Mobile Device Management server, Exchange ActiveSync, or iCloud). Erasing the key in this manner renders all files cryptographically inaccessible.