Rosyna

hungover said:

foggyhill said:

Didn't we ALREADY know that. I actually knew that without even trying (because I'm a computer engineer).
That; why Apple changed it later.
It's not an easy attack though; if a person is doing that to your phone, I'm guessing you can spring for an Iphone 7...

If Apple were aware that the data could be extracted from the 5c using that technique why did they refuse to help the FBI and insist that the only way to extract the data would require custom code that could fall into the hands of criminals?

Apple could have helped the FBI and then said "sorry guys, as much as we'd like to, we can't help you with any newer handsets" . Doing so would have been likely to have strengthened their case against future law enforcement demands and saved the public purse a shed load of money.

No, what it proves is that the FBI never needed Apple's help at all. That the FBI's attempt to coerce a
Apple was just to set a precedent so Apple couldn't refuse to help them in the future.

That's also why the FBI used a phone in PR that they knew had absolutely nothing of value on it.

The fix would be for WhatsApp to either move to encrypted CoreData (as the article suggests) or, more simply, to just use the SQLite VACUUM command (https://www.sqlite.org/lang_vacuum.html) on the app tombstoning notification (https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/StrategiesforHandlingAppStateTransitions/StrategiesforHandlingAppStateTransitions.html#//apple_ref/doc/uid/TP40007072-CH8-SW24) if any chats had been deleted.

The latter fix is more likely to occur with WhatsApp because it's almost trivial to adopt.

Where both the .zip and .dmg files have rudimentary checksums to warn the user that it may have been corrupted in transit, there are no safeguards against tampering. 

As of Mac OS X 10.11.5, the codesign tool supports signing disk images (https://developer.apple.com/library/prerelease/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG18).

The purpose of the xip format and signed disk images isn't to prevent things like XcodeGhost, which was correctly stopped by Gatekeeper because the code signature was invalid. It's to exclude an app from the new App Translocation security feature (http://lapcatsoftware.com/articles/app-translocation.html) in Sierra. App Translocation was designed to fix a Gatekeeper vulnerability (http://arstechnica.com/security/2016/01/how-malware-developers-could-bypass-macs-gatekeeper-without-really-trying/) that allowed malicious actors to hijack signed (usually by Apple) applications by forcing them to load malicious external resources that are located in specific places on disk relative to the signed binary.

That is, the ability to use signed xip archives and signed disk images is only useful on Mac OS X 10.12 or later.

The reason why Xcode 8.0 beta is shipped as a xip and not in a signed disk image is because the Xcode beta is freakin' huge! After decompressing it, Xcode 8 comes in at over 12GB! As a disk image, you'd be required to have both the disk image and Xcode exist on disk at the same time because you'd have to download it, mount it, copy Xcode to /Applications (which requires the Disk Image framework to decompress Xcode while copying it), unmount the disk image, and then delete the original image.

A xip permits Archive Utility to do the decompression and deletion for you. If your Downloads folder is on the same volume as /Applications/, then only an additional move, not a copy, it required.

cali said:

Wait a f**ing minute. You mean a big similar to android was capable on iOS?

Stagefright is one of the biggest reasons why I defend iOS. Tell me it isn't the same only "similar" in a clickbait manner.

Can it be triggered without opening a message like StageFright?

It wasn't really similar for messages because there was no way to easily get out of the Messages sandbox without a separate exploit, especially given the privilege level Messages runs at. The issue with Stagefright is that Android had/has numerous known sandbox exploits that went unfixed based on which OEM made your phone.

The "passwords" thing only applied to Safari crashing when displaying the TIFF and it only had access to data in MobileSafari's address space (or APIs Safari had access to that didn't require XPC service privilege checks). This pretty much limited it to cookies and any websites you had visited with login forms visited during that Safari session (iOS frequently tombstones Safari in the background, which purges this memory).

Either way, it was announced after Apple had pushed out the update that fixed it. 

It's not specifically being added for Safari. It's being added to ImageIO, so all apps automatically get WebP support.