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
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.
> 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.
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.
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.
If it has such access, and if that access is unrestricted (both possible and reasonably likely, but not guaranteed) then the WiFi CPU could easily get the main CPU to do whatever it wants.
I'sure mikeash means main RAM, not the wifi internal memory. Given DMA to systm RAM, your device is rooted. Given access to wifi chip's RAM, rooting is probably much harder (but still not impossible.)
Apple's been shipping hardware DMA restrictions on Macs for awhile - that first appeared on the security radar in the FireWire era – so it's not inconceivable that it's not as simple as getting DMA access but https://www.apple.com/business/docs/iOS_Security_Guide.pdf seems to be silent on that unless I'm missing something.
IOMMUs are important for external interfaces, but much less so for internal hardware. It's certainly possible that they're doing it here, but I wouldn't bet on it.
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.
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?
Allowing downloads of OS updates less than 100MB over 3G/4G, just like regular apps?
The 10.3.0->10.3.1 patch is ~20MB. My phone downloads multiple ~100MB app updates daily over cellular. Refusing cellular iOS updates that are smaller than one of those apps is getting pretty silly these days.
Apple sees devices as portals to the same content. Whether you currently have an iphone in your hand, a mac, the watch, an ipad, whatever, Apple sees them as interchangeable to do the work you need. So while I may be using an iphone/watch on the bus ride home, when I'm home I can grab my ipad and try to seamlessly switch what I was focused on to it.
The try is the hard part that I think they are focused on and will continue to decrease friction in the future.
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.
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.
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.
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
This comment appears to add additional, specific information to my general comment rather than disagreeing with what I said, but the comment starts with "no", which implies otherwise.
The core idea here is that SSL is not necessary if the data is signed through some other mechanism.
I think "no" was due to "you can distribute updates offline or from your own server and devices will still accept the updates." I assume you just meant that as a general thing, but one could read the comment as saying that because iOS signs updates this way, it can do offline updates.
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.
> 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.
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.
What makes you think it isn't privately owned? It's true that the domain can't be bought, but you still hit a Verizon server when you go there.
And if you're using an iDevice, you might as well go to http://captive.apple.com, which was designed for the purpose of authenticating to hotspots and Apple already knows who you are anyway. :)
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.