About the security content of iOS 10.3.1

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

by okket • 9 years ago

147 44 9 years ago

support.apple.com

danielvf• 9 years ago

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

That's a major problem!

RKearney2• 9 years ago

And yet Apple requires you to download this update over Wi-Fi to receive it OTA.

Sure you could update via a computer, but that seems to go against Apple's vision of not requiring tethering your device to a computer every time you need to update/sync/setup.

digi_owl• 9 years ago

Funny how that goes, as back when the iPod was new the idea at Apple was of the Mac to be the heart of a ecosystem.

JustSomeNobody• 9 years ago

That's a rather loose definition of requires.

evilduck• 9 years ago

What do you propose then? Typing in the patch?

djrogers• 9 years ago

So by 'requires' you mean offers it as one possible option? Your post already mentions the most obvious alternative - update via iTunes, and you can also use the lightning-USB adapter and a USB NIC.

I'm not sure I really understand the purpose of your post here, unless it was to incite some sort of ire from Apple haters?

devy2• 9 years ago

Honest question, is "execute arbitrary code on the Wi-Fi chip" the same as execute arbitrary code on the SoC (e.g. A10) chip?

mikeash7• 9 years ago

It's not identical. The WiFi chip has its own processor running its own code, and that's what the exploit affects.

It may be possible, even trivial, to leverage that into running arbitrary code on the main CPU, depending on how the stuff is designed. If the WiFi chip has unrestricted access to RAM then that would be it. If not, it's likely that the OS drivers for the chip aren't hardened against malicious input from the WiFi chip and could be exploited.

bdrool3• 9 years ago

Something I just noticed about the iOS update process: it appears that when it tries to "verify" an update (which requires that you be online), it does not do so over a secure connection. I was on a captive network (the kind where HTTPS goes through but plain HTTP does not, until you click through an agreement page), and while it was able to download the update just fine, it couldn't verify it until I opened Safari and tried to go to neverssl.com to click past the captive network's "I agree" button. Doesn't that seem wrong? Or perhaps it's just the "check to see if the user is online before verifying" step that is unsecured. Either way that seems like a bug.

klodolph2• 9 years ago

The way iOS and macOS applications are verified is by signing the application package itself, presumably the OS updates use a similar mechanism. At that point it is irrelevant whether the connection used to download the package is secure. This is similar to the way that packages for most (sane) Linux distributions are signed. The advantage to this technique is twofold: that there are network environments where SSL communication is not possible, and you can distribute updates offline or from your own server and devices will still accept the updates.

0x03• 9 years ago

No, iOS updates require online validation because the boot rom will issue a one-time challenge based in part on the device's unique serial number, and it needs to be granted a "ticket" response by the apple servers. This is why you usually can't downgrade iOS versions (as the apple servers will refuse to grant a ticket for old versions). Google keywords: apnonce, apticket, shsh blobs, signing window

bdrool3• 9 years ago

As I mentioned here[1], it's more about the user experience than security, sorry, I should have been more clear.

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

analogist• 9 years ago

That seems to be pretty weak evidence of verification not being through TLS. There could easily be an additional connectivity check that is http-based (that was blocked by the captive portal) before proceeding onto a standard TLS handshake.

As 'klodolph mentions, there's a lot of layers of verification for software updates. Before install proceeds, the verification requires a cryptographic signature from an Apple authorization server in response to submitted device ID + hashes of the package to be installed. Then at boot time, the signature is verified again by the standard boot process (burnt-into-silicon Apple root CA pubkey verifies the bootloader integrity, which then verifies the iOS kernel integrity, which then re-hashes the update package and re-verifies the signatures to make sure there's not a rootkit or MITM interfering with hashing and verification). Only then is an update actually allowed to be installed.

bdrool3• 9 years ago

There could easily be an additional connectivity check that is http-based (that was blocked by the captive portal) before proceeding onto a standard TLS handshake.

Yes, I mentioned that in my comment.

As 'klodolph mentions, there's a lot of layers of verification for software updates.

I realize that, but my point is that apps that mix HTTP and HTTPS connections have a tendency to provide strange and confusing feedback to the user in situations like this. Some operations work, some don't. Apple News for example will load text but no images on unauthorized captive networks like the one I was using. An app that I worked on had the same problem (API calls went over HTTPS, but CDN-served content did not), and it was always confusing to users when secure connections went through but non-secure did not (or vice-versa). From what I've seen, it's a much better experience and much easier for the user to understand if all connections are treated the same. Having a mixture can lead to confusing situations where some things fail and some don't, and it's very hard for a non-technical person to know why. It just seems broken to them.

For example: think about the experience I had. The device appeared to be online, even downloaded the system update just fine, but then suddenly the Settings app complained that I was not online, even though many network functions (such as email) were still working just fine. A natural response might be to say that captive networks are the problem, but I promise that non-technical users will not see it that way. They will not blame the network. They will blame the app. In their minds, they are either online or not, and if only certain things fail, those things must be the problem.

Captive networks suck, but they are a reality of the world we live in and are not going away. Writing apps such that they always treat connections in the same manner will be far more understandable for users in the long run.

harikb• 9 years ago

The captive networks I have seen do the opposite. HTTPS does not go through until an HTTP link is accessed to generate the 'I agree' page. Probably why neverssl.com exists in the first place.

nkristoffersen• 9 years ago

on the topic of neverssl.com, just use example.com as it is not privately owned.

dep_b• 9 years ago

Could this also work on "cold" devices, so devices that have Wi-Fi but it's turned off?

danudey• 9 years ago

Presumably not, since the wifi chip in those cases is usually powered down entirely (hence why it can't be used for geolocation).

duskwuff• 9 years ago

Receiving any sort of communications over wifi would require the radio to be powered on, and sucking down battery the whole time. There's no way Apple would have missed such an obvious way to extend battery life -- I'd be surprised if it's even powered on unless the phone is actively communicating on the wireless network.

0x03• 9 years ago

It looks a lot like this google project zero bug (same reporter, same bug type (stack overflow on the wifi chip)) but the CVE number has the last two digits swapped

https://bugs.chromium.org/p/project-zero/issues/detail?id=10...

Looks like it's hitting android devices as well as ios devices?

Edit: Apple must have known when they released iOS 10.3.0 since they named the next-day-beta 10.3.2. Perhaps they were embargoed because of other broadcom customers, but didn't want to delay the other crazy security fixes that 10.3.0 brought. Were they forced to ship an known insecure broadcom firmware because of Android then? Double edit: Or more likely they just wanted to get some more testing time. Looks like the p0 bug was unrestricted on Mar 23.

jeroenhd2• 9 years ago

Very interesting to note:

However, searching a small sample of firmwares I have present, I've been able to verify the existence of the "ccx" tag in the Galaxy S7 (G930F, G930V), Galaxy S6 Edge (G925V), Galaxy S7 Edge (G935F, G9350), Galaxy Note 4 (N910F) and Galaxy S5 (G900F).

This could mean that not only Apple devices are affected. Broadcom chips are everywhere and bringing out patches and firmware update is a big problem in the Android world.

tedunangst• 9 years ago

Well, it's quite obvious to see what went wrong.

    void function_79390(void* unk, char* ie, char* buf)

Those are terrible names for functions and variables. Very shoddy development.

jeroenhd2• 9 years ago

This is probably decompiled code. Many functions loose their names if code gets optimized or obfuscated. function_XYZ is probably a placeholder used by the decompiler.

ben1040• 9 years ago

Looks like it's hitting android devices as well as ios devices?

The April Android security bulletin went out today and there were several new Broadcom wifi related vulnerabilities addressed on it too.

https://source.android.com/security/bulletin/2017-04-01.html

About the security content of iOS 10.3.1

Related Stories