The security content of iOS 10.3.3

https://support.apple.com/en-us/HT207923

by codezero • 9 years ago

170 82 9 years ago

support.apple.com

0x07• 9 years ago

Interestingly, the changelogs are silent about a fairly major change to the filesystem when going from 10.3.x to 10.3.3. It seems like APFS was originally intended to use a different unicode normalization setup than HFS, but it turned out to be very problematic. After iOS 10.3.0 silently converted all iOS devices from HFS to APFS (!) (and not only was this not specified in the user-visible changelogs, earlier iOS 10.x.x releases did the same dry-run conversion without notice - only stopping short of committing the final type flip - which may explain why iOS OTA upgrades have been somewhat slow to execute - https://www.macobserver.com/analysis/apple-dry-run-apfs-prio... ), iOS 10.3.3 adds runtime normalization to the file system. It's unclear what kind of performance hit this has (but I seem to remember reading something about how samba on UNIX taking a hit on file opens in order to support clients specifying incorrect casing, which sounds similar). Apparently an unspecified later version of iOS will perform yet another conversion, from APFS-normalization-preserving to APFS-native-normalization.

More details: https://mjtsai.com/blog/2017/06/27/apfs-native-normalization...

By the way, if you ever rsync between macOS and Linux you may have noticed (or not) how this unicode normalization messes up filenames and cause duplicates and stale copies when roundtripping, see https://serverfault.com/questions/397420/converting-utf-8-nf...

Also, unrelated, it seems this version of iOS fixes the Broadpwn wifi chip vulnerability (which perhaps could also continue on to compromise the main OS kernel via a DMA attack after compromising the wifi chip) ( http://boosterok.com/blog/broadpwn2/ , https://nvd.nist.gov/vuln/detail/CVE-2017-9417 )

timcederman• 9 years ago

After iOS 10.3.0 silently converted all iOS devices from HFS to APFS (!) (and not only was this not specified in the user-visible changelogs

Are you suggesting Apple didn't disclose APFS was coming to 10.3? There was plenty of media coverage ahead of time (e.g. https://9to5mac.com/2017/03/21/what-is-apples-upcoming-apfs-...), and it's specifically mentioned in the 10.3 release notes.

urda• 9 years ago

It was absolutely disclosed all over, so I'm not sure if this is simply the commentor being wrong (most likely) or a weak jab at Apple.

https://developer.apple.com/library/content/releasenotes/Gen...

0x07• 9 years ago

I don't think it was mentioned anywhere in the end-user facing "software update" changelog - if this is the right source https://support.apple.com/kb/DL1893?locale=en_US - but you are right that it was mentioned in the developer SDK release notes https://developer.apple.com/library/content/releasenotes/Gen...

noja• 9 years ago

By the way, if you ever rsync between macOS and Linux...

Syncthing handles this with automatic normalization: https://docs.syncthing.net/advanced/folder-autonormalize.htm...

vvhn3• 9 years ago

from APFS-normalization-preserving to APFS-native-normalization.

The developer documentation at [1]

seems to suggest that "native" normalization is normalization preserving as well and that native normalization is based on storing the hash of the normalized name instead of storing the normalized name itself.

" and preserves both case and normalization of the filename on disk in all variants. "

and

" APFS preserves the normalization of the filename and uses hashes of the normalized form of the filename to provide normalization insensitivity, whereas HFS+ stores the normalized form of the filename on disk to provide normalization insensitivity. "

edit - Even the linked blog post says the same thing

" macOS 10.13 will also support case-sensitive APFS, which will use native normalization. This is new in the developer beta. The filenames are still stored in the same way as prior APFS (not normalized like with HFS+), but APFS now uses normalization-insensitive hashes ... "

how this unicode normalization messes up filenames and cause duplicates and stale copies when roundtripping

Being normalization preserving should fix that, right ?

1 https://developer.apple.com/library/content/documentation/Fi...

acranox• 9 years ago

I wonder if the change to the filesystem is why my phones performance feels so sucky the last few months. I have an iPhone 6. it starting hanging for several seconds at various times. It didn't used to suck this much.

Eric_WVGG• 9 years ago

Most reports say it's faster, the experience on my iPhone SE has certainly been just fine. I would consider backing up, wiping, and restoring from backup perhaps.

pjmlp2• 9 years ago

2 x "A buffer overflow issue was addressed through improved memory handling."

7 x "A memory corruption issue was addressed with improved bounds checking."

Oh well....

pqdbr• 9 years ago

With 13x arbitrary code execution, being 5x with either kernel or system privileges.

hellbanner• 9 years ago

Yes, and previous decimal versions had similarly powerful exploits.

PhantomGremlin• 9 years ago

This is depressing.

I normally shrug off security vulnerabilities in iOS. But so many in such a minor release?

I know it's not a valid extrapolation ... but if there are so many being fixed just today, that means there are hundreds if not thousands of still undiscovered ones remaining.

And Android is probably even worse.

To repeat myself: this is depressing.

ccrush• 9 years ago

https://technet.microsoft.com/en-us/library/security/ms17-01...

This is Microsoft's patch covering ShadowBrokers-leaked ETERNALBLUE SMB remote code execution 0day. The iOS 10.3.3 is likely the response to either the CIA Vault7 Wikileaks stash or the ShadowBrokers NSA EquationGroup stash. These exploits are probably out there in the hands of many people, and Apple had to respond.

vijayr02• 9 years ago

Or maybe... just maybe, an agency belatedly realised the "Defending Our Nation" part of its motto really means something.

BinaryRage• 9 years ago

They should rewrite in Rust...

pjmlp2• 9 years ago

No, they should stop using C or C style coding in C++, and write those parts in a mix of modern C++17 and Swift.

p0ppe2• 9 years ago

I'm still perplexed that Apple doesn't offer over the air updates, especially for security updates. 137 MB shouldn't be that big a deal on a normal 4G connection.

0x07• 9 years ago

Agreed, this is super annoying. You can install dozens of 99MB apps over 4G every day but nooo you can't have your broadpwn fix on the move. Except if you happen to have two devices with 4G, then you can wifi-hotspot-tether one to the other and vice versa for the update just fine.

spike021• 9 years ago

Not everybody has unlimited data plans.

4G can certainly handle 137 MB in speed, but that doesn't mean users want to use their data plan for updates.

0x07• 9 years ago

Then at least allow it for manual update requests. Just like 99MB app installs or updates don't have a problem with 4G :)

p0ppe2• 9 years ago

But that should be up to the users to decide. I'll be much happier to use up 137 MB for a critical security update than 354 MB for the latest Facebook app update (version 132.0).

jelder• 9 years ago

These should be exempt from data caps then.

cstrat2• 9 years ago

Strange my update was 1.8GB?

LeoNatan252• 9 years ago

Did you have a beta release installed? Usually those are hit with a “full” update when GM version drops.

icedchai• 9 years ago

Do you remember when you had to use iTunes to update iOS? Being able to update over wifi was huge...

65827• 9 years ago

Should be 84MB doing from 10.3.2-> .3, that should be about 90% of use cases I think

arprocter2• 9 years ago

Another oddity is the podcast app won't let you download something 100MB+ over cellular, but will happily let you 'stream' it.

I have unlimited data - let me use it.

lathiat• 9 years ago

Unlimited data plans is exactly what those limits are there to try and protect.

DINKDINK• 9 years ago

137 MB shouldn't be that big a deal on a normal 4G connection.

"I can download a 137MB file when I want over a 4G connection when I want" does not equal "The entire 4G network can handle the high coincident demand of all iPhone users downloading 137MBs simultaneously"

zyb09• 9 years ago

That would be absolute madness. Can you imaging Apple pushing a 137MB file to all active iOS devices over cellular? I'm sure the carriers would appreciate :)

bpicolo• 9 years ago

That would be brutal on networks in populated areas I suspect. On update days our office network usage is huge.

URSpider94• 9 years ago

I wager that they have agreed not to do so in their carrier agreements.

rdl• 9 years ago

I wish there were a cellular broadcast mechanism for data like this. Sending out OS updates, cache prefill, etc. to everyone on a cell network during low use periods would be interesting.

ProfessorLayton• 9 years ago

They still haven't addressed the permanent website data bug in Safari.

Go to Settings> Safari> Advanced> Website Data and try and clear it. Some websites won't delete arbitrarily, and if they do, others will stick. This happens even in private browsing.

GeneticGenesis• 9 years ago

Have you filed a radar bug?

nikanj• 9 years ago

In my experience, those are about as useful as telling your dog about the bug. Complaining on HN has a slight possibility someone from Apple might actually see the bug, and fix it.

brisance• 9 years ago

And I thought I was the only one to experience it. Had that fixed months ago but didn't think enough of it to save the solution for posterity.

CodeWriter232• 9 years ago

Anyone know if the WiFi exploit opened the door to arbitrary code execution on the main CPU?

inertial• 9 years ago

If you are referring to broadpwn aka CVE-2017-9417 [1], it has been fixed (last item in [2]).

[1] https://news.ycombinator.com/item?id=14727400

[2] https://support.apple.com/en-us/HT207923

Summary :

Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip

Description: A memory corruption issue was addressed with improved memory handling.

CodeWriter232• 9 years ago

This is what I'm interested in, and I saw that Apple fixed the exploit enabling attackers to own the WiFi chip. What I want to know, does owning the WiFi chip on machines not having the patch provide a beachhead to exploiting the iOS kernel. And if so, are there known active exploits at that level?

stock_toaster• 9 years ago

Wasn't there another remote buffer overrun vuln in broadcom's wi-fi chips reported back in april too? yikes...

EDIT: found it[1]

[1] https://www.theregister.co.uk/2017/04/05/broadcom_wifi_chip_...

tarikozket• 9 years ago

So pretty much anyone was able to execute anything on our phone remotely. Lol.

Tanegashima• 9 years ago

No, it’s not like android or windows.

Piccollo• 9 years ago

Haven't heard of anything public though

The security content of iOS 10.3.3

Related Stories