The security content of iOS 10.3.3 | Hacker News Reader

The security content of iOS 10.3.3

support.apple.com

170 pointscodezero82 comments

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 )

> 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.

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...

Those release notes are intended for their developer audience, not the general end user base. Parent was pointing out that the actual release notes Apple shows you on the device you're about to upgrade did not mention APFS.

The general audience doesn't even know that its phone has a file system, let alone care whether it's HFS, HPFS, APFS, or CP/M. You're complaining that Apple didn't disclose something that only developers care about to the masses.

Then at least we can agree that a fairly major operation such as converting the entire disk between file systems in a "minor" update wasn't disclosed to the masses, and I think that fact (and that it worked out quite well, apparently, besides the normalization shenanigans) is interesting it its own right.

I think it's important to distinguish a major change from an impactful one. The APFS change is major, but not necessarily impactful in any meaningful sense to users. Apple's not the kind of company that's going to emphasize non-impactful changes to its customer base.

I'm not sure I agree with that, obviously this seems to cause trouble if you have file names with non-ascii characters in them already, and who knows what else could have gone awry. But let's agree to disagree in that case :)

0x0 (since this thread has hit the reply depth limit): The filesystem on iOS isn’t exposed to users, so I would guess that Apple considers it a strictly developer-facing change.

That's not necessarily true. It's easy to build an app where you prompt for the user's text input to construct a filename for saving a document/picture for example. NSDocumentDirectory is very much still the recommended place to store persistent user data on iOS. Imagine any non-English speaking person entering a non-ascii name for their document.

As another example, imagine Dropbox.app syncing files from the dropbox cloud reusing explicit filenames into the app's sandboxed Application Support/Library/Documents folders. I have no if they do this but if they do this could spell trouble.

Or simply any app supporting iTunes File Sharing, allowing users to drag files from their mac into the app container's NSDocumentDirectory directly.

Edit: Interested in hearing counterarguments instead of downvotes, thanks? :-/

>Imagine any non-English speaking person entering a non-ascii name for their document

You mean there are people in Europe, China, Japan, India running into widespread problems when they create filenames in their own language in iOS 10.3+ ?

It’s a lot more subtle than that. Under certain (very) edge cases, there may be an issue.

Yes. There's some details here:

https://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filena...

The clearest explanation is in one of the updates on that page:

"The most obvious problems arose with iOS users who transferred files from Windows (which prefers a different normalisation form to HFS+) which were named using Korean and other character sets, although this even included European languages with accented characters like ñ and é. There’s a chilling series of messages on the Apple Developer Forums in which an iOS app developer details how users running iOS 10.3 were transferring files using iTunes for Windows, but could not access those files once they were on an iOS device."

The "chilling series of messages" takes you to a link which details how File sharing through iTunes on Windows specifically was affected and that a similar file transfer product on Windows iMazing was able to fix to fix it by simply normalizing before transferring. ( The "bag of bytes" response from Apple asks developers to do exactly that btw )

That begs the question that why iTunes itself ( on Windows ) wasn't able to do the same thing as iMazing ?

Anyway that's moot now - As mentioned earlier in this thread iOS 10.3.3 and iOS 11 are changing behaviour w.r.t. this.

What do you mean by reply depth limit? I'm able to reply to your comment... :-/

To stop flame wars (or slow them down) the deeper you get in a thread the longer it takes the reply link to show on the deepest comment. So if we get 20 levels deep in 30 minutes, the reply link may take tens of minutes to show up.

Sometimes this catches other discussion types.

It's worth pointing out that you can always reply to a comment on its own page, regardless of whether the reply link exists in the main thread.

Indeed, just click the "1 hour ago" link.

That's what was confusing me as that's how I replied. Good info all around. :)

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...

This makes sense to me - why would the user care what kind of filesystem their phones have - developers might - but when you cant choose the filesystem anyhow, what does it matter if the default changes.

> 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...

>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...

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.

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.

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....

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

Yes, and previous decimal versions had similarly powerful exploits.

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.

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.

That Microsoft link lists 6 CVEs.

Apple's security content page lists 48.

That's probably an unfair comparison. How many vulnerabilities have been patched for all of those leaks / stashes by Apple and Microsoft?

It seems like we'd need to know those numbers in order to fairly judge whether PhantomGremlin should feel depressed or not.

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

They should rewrite in Rust...

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.

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.

Have you filed a radar bug?

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.

I'd disagree, I've filed probably 15 in the past 7 years for obscure bugs and all of them were fixed. They don't respond and the fixes take a long time, but I'm pretty sure they are listening.

I’ve used the built in Feedback app several times and received replies asking for follow up so it’s fair to say they are listening

Not that this will instil a huge amount of confidence, but I filed a bug about a XNU kernel syscal that returned the wrong error code. They shipped a fix two years later and closer the ticket.

I provided a diff fixing the bug but ¯\_(ツ)_/¯

To be fair, they can’t use your diff without you signing it over as it may be copyrighted

If it was just changing a constant (which is what GP implied), that would probably not constitute sufficient creative output to be subject to copyright.

To be more fair, they didn't ask me to.

I can assure you, radars have ∞ more chance of getting something changed verses just compaining about it on a website.

File the radars.

I would be more inclined to file them if I didn't have to consult an independent third party (open radar) to (hopefully) see what's going on with the radar referenced when one gets closed as a dupe. The more you make it a chore to file or track bugs the less likely I am to bother.

No. Please file a radar. They get read and the more dups increases the likelihood it'll be addressed.

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.

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

No, it’s not like android or windows.

Haven't heard of anything public though

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.

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.

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.

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

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).

FYI even though it says 324mb, App Store updates are delta updates as of iOS 6

https://developer.apple.com/library/content/qa/qa1779/_index...

Coming from 10.3.2, the 10.3.3 update was 84.4 MB for me.

These should be exempt from data caps then.

I don't know where you fall with Net Neutrality, but you can't have Net Neutrality and updates exempt from data caps.

Hmm, interesting. Updates, and especially security updates, can be seen as a common good. It's the only kind of thing I can think of that exemptions from data caps might be a good idea for.

Strange my update was 1.8GB?

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

Ah yeah I was running the Beta for iOS10. Makes sense. Cheers :)

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

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

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.

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

But presumably streaming the whole thing will use the same amount of data as downloading.

100MB seems rather arbitrary, and there is no option to change the max size/disable the 'feature'

>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"

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 :)

I highly doubt the engineers at Apple wouldn't think of that and work around it.

You mean like only allowing the update over wifi? ;)

The thread is about if they allowed updates over 4G, so not a solution.

That was a joke about how only allowing it over wifi is the workaround (to prevent saturating the network) you mentioned...

> engineers at Apple wouldn't think of that and work around it

How is it any different to an update to a large and popular app on Android... Facebook for instance?

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

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

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.

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

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.

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?

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_...

Reply on news.ycombinator.com