Apple: Heap Overflow in AppleBCMWLANCore Driver | Hacker News Reader

Apple: Heap Overflow in AppleBCMWLANCore Driver

bugs.chromium.org

137 points0x067 comments

Interestingly this was not part of the original iOS11 security announcement: http://web.archive.org/web/20170919182359/https://support.ap... and (a mail to apple-security which is no longer archived at https://lists.apple.com/archives/security-announce/2017/Sep/... )

But instead published after the fact as an additional update: https://lists.apple.com/archives/security-announce/2017/Sep/... and https://support.apple.com/en-us/HT208112

Why delay the announcement? And why remove the original "APPLE-SA-2017-09-19-1 iOS 11" with "Date: Tue, 19 Sep 2017 -0700" from the apple-security email archive?

Also, are Macbooks vulnerable to the same bug until next monday when macOS 10.13 drops?

Also, there are about 6 other similar issues recently posted to Google Project Zero: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

Is this going to be fixed in iOS 10? Some users have apps which will not work with iOS 11, so cannot immediately upgrade.

Highly unlikely, I don't think Apple has ever released multiple branches of updates for any device. The closest is perhaps iOS 6.1.6, a fix for the fatal "gotofail" SSL vulnerability, which was pushed out to devices stuck on iOS 6.x, but if your device was eligible for iOS7 then iOS7(.0.6) was what you would get.

That's also the only time I can remember security updates being pushed after a device model being end-of-life'd.

Have they previously had an app transition like 32-bit / 64-bit, where some users cannot upgrade?

Nope, so this is going to be interesting to watch. Personally I was hoping that they would offer an optional download of 32bit support libraries to let iOS11 users run important existing legacy apps and access their documents, but they seem to push hard on making developers get in line and update their apps. Which is unhelpful for the cases where the developers no longer have any interest in their apps or even exist (bankrupt, disbanded, in some cases deceased)

If the developer is bankrupt, disbanded or deceased then the app generally can not remain published for longer than a year at most anyway.

If the developer does not have any interest in updating their own app, do I as a user care about their apps?

> If the developer does not have any interest in updating their own app, do I as a user care about their apps?

A developer's primary interest in their app is to earn an income. A user's interest is in using the app for whatever functionality it provided. There's no symmetry here.

If the developer doesn’t want to update their apps to fully support my device, then I would look for an alternative.

There are almost 0 cases where I would withhold an OS update in order to keep using an specific app, let alone change my device, and I’m completely on Apple’s side for finally killing 32-bit.

What was the point of that be? The apps aren’t going to be updated if they haven’t in the last four years. Keeping all that stuff around is also support burden for Apple.

If they only supported it on the 7 and below then it might be confusing to users why some people get to use older apps and others don’t. On the other hand if they wanted to support it on the 8 and X then they would have to have an entire processor emulator that would only exist to support apps that hadn’t been updated in years.

Don’t forget that Apple keeps tons of usage statistics from people who are willing to give them. Chances are they know pretty exactly what percent of people use 32 bit apps with any regularity and how much total time to use them for. If they were willing to make these decisions my guess is those numbers are very low.

People here on HN are concerned about it and there have been some articles on websites about it but I’m willing to bet that this whole thing is almost a non-issue.

What legacy apps worth keeping “documents” for - I’m assuming non game apps — would be worth supporting? The chances are even if they did provide support for 32 bit abandoned apps, they would break sooner or later with a future OS upgrade.

Besides are you planning on keeping the same IOS device forever? The newest processors are 64 bit only. I doubt that Apple will ever release a new device that will support 32 bit devices - except for maybe a new iPod Touch or iPhone SE.

It's not just a matter of the space on disk to hold 32-bit libraries. They must also be loaded into memory if there are 32-bit processes running. This degrades performance system-wide, not just for the abandonware apps.

What good is RAM for if not running the applications a user needs to run? If the user is not currently running a 32bit app, drop the libraries from RAM. That is such a non-argument. The amount of space and time needed to load and unload 32bit support libraries is probably 1% of the space and time used every time a user loads a game, or the facebook app, for example.

>What good is RAM for if not running the applications a user needs to run?

What good is degraded performance because some BS game/app who on top of it is abandoned from its developer for years, and it will stop working anyway sooner or later, needs 32-bit mode? Especially when you can find 200 replacement that work fine in 64-bit and are upgraded regularly.

Where do I find 200 replacement apps for a car unlocking app? https://news.ycombinator.com/item?id=15302231

If your car can only be unlocked by your phone you made a mistake when buying it. Just like if it features proprietary chargers. These things just don't last.

I see. Is buying an iphone or an ipad a mistake as well? They require proprietary lightning cables to charge.

You can still buy new cables that fit the first iPhone today but you can’t buy a new iPhone that fits the 30pin charging dock in old cars.

The main difference though is that you’d expect a device like an iPhone or iPad to last a maximum of about 3 to 5 years while you’d expect a car to last 10 to 25 years. Accordingly it would be wise to use future proof parts, not proprietary parts that go out of style every few years.

That's the point here, if (offline) apps randomly break then your platform is crap. Anything cloud-reliant (in that case) would have broken a long time ago anyway and isn't really relevant.

If a customers pays Apple $1000 for a device and uses that device to create valuable data which cannot be migrated to another app, they may expect their device to continue providing the functionality for which it was purchased. It still contains their data + app. Customers want access to their DATA, not apps, not devices - those are mediating tools which change over time.

If Apple wants to force apps to do something, they can force developers to create interoperable data that can be migrated without the developer's consent or continued existence. Until then, Apple has more resources than Microsoft and Linux, which both provide backward compatibility for old apps on new platforms. This is a solved problem.

Why penalize iOS platform customers who were the earliest adopters and had the highest chance of creating data which is now orphaned in abandoned-but-functional offline apps? Let's not get into the Apple's mis-steps on the App Store, which is what caused many iOS developers to go out of business or stop supporting apps.

>Which is unhelpful for the cases where the developers no longer have any interest in their apps or even exist (bankrupt, disbanded, in some cases deceased)

If they are "bankrupt, disbanded, in some cases deceased" then maybe insisting on using those apps are not the best course for the user either...

As I commented last time on the subject: https://news.ycombinator.com/item?id=15285252

Sometimes the apps are the only way to access something else, in this case a car remote unlock.

Sometimes someone has paid actual money for an app, more than the $1 baseline; some music apps are in triple figures.

This is a valid concern, I don't understand why you are getting downvoted.

Not on iOS although it has happened on the Macintosh twice.

I thought they kept doing security updates for 32 bit macs for a little while?

They did, and they’ve been doing that on iOS. The first 64-bit devices came out for years ago.

I was actually thinking of when they left 68K and PowerPC though. I had PowerPC apps that worked through Rosetta for a while and then that was removed when Apple decided it was “time“.

Versions older than the latest macOS get updates all the time, I don't see why this wouldn't be the case here

Historically, this has only happened once on iOS, as far as I know. It'd be great if you were right.

Yes, it seems Apple only gives version number updates to the latest version of iOS https://support.apple.com/en-us/HT201222

Not sure if they can/do update independent components though

They’ve done it before - released an update for an older OS after the newer one was introduced - but never for a device that was capable of running the newer OS.

There's also an issue with the stock Mail app in iOS 11 and O365 email that's keeping people on iOS 10.

Wonder what this means in the grand scheme of things. Will Apple dump Broadcom and go with Qualcomm or attempt to fix Broadcom's broken driver.

I say broken as I've yet to see good code come from Broadcom.

This is a bug that was already fixed. It means nothing in the grand scheme.

In the current grand scheme, Apple and Qualcomm are also currently suing each other and I'm pretty sure part of that is Apple withholding billions in payments.

This is a Hacker News post about an interesting security vulnerability. It is, by both moderator and owner intentions, specifically meaningful in the 'grand scheme' of Hacker News, a site set up to permit people to discuss links.

Yes, at a different level of business, Apple has an open lawsuit against Qualcomm, but that's not the scope that we're here to discuss. Mentioning it is fine, linking to a recent HN post about it would be stellar!, but "It means nothing in the grand scheme" is dismissive and wrong.

Your concerns are clearly expressed, but insulting others for choosing to discuss a topic not relevant to your concerns is no excuse to shut them down verbally. That approach is not welcome here.

EDIT: I'm not a mod or anything.

You are not a mod, you are a fool responding to a comment without ever reading the comment mine was in response to. What the fuck.

Whoa. Attacking another user will get you banned here regardless of how bad some other comment was. Please read https://news.ycombinator.com/newsguidelines.html and don't ever post like this again.

This isn't even in Broadcom code.

Maybe not this time, but they have a history of fatal firmware bugs that could compromise the host system - such as http://boosterok.com/blog/broadpwn2/

For what it's worth, Broadcom's market share in attractive heavy-firmware wifi adapters is pretty high. They could just be an exploit magnet.

Does that mean that all embedded WiFi (and probably also baseband) controllers are deeply rotten, and we only blame Broadcom so far because of their popularity with device manufacturers?

Pretty much.

In general, you can assume that if you can't audit it, it's absolute crap. This is true for hardware and software.

These companies with widely available low level firmware should really switch to Rust.

I love rust and have rewritten a dozen cross-platform utilities in it, but rust is nowhere near usable for general purpose embedded development.

why??

Go with Qualcomm? Last time I check Atheros aren't any better software wise and much worse in hardware.

I am not sure if there are any real alternative to Broadcom WiFi and Ethernet, apart from Apple making one themselves.

( The W1 and W2 may be part of this )

Is every buffer overflow important enough to need detailed discussion and commentary?

I think these latest sets of wifi flaws are interesting if it turns out they are exploitable by merely being in radio range of an attacker even without joining a malicious network or requiring user interaction. That could quickly become a fast and wormable attack. You could probably flood across an entire city jumping from chip to chip in no time.

Especially now that iOS 11's wifi-off button in the control center no longer actually disables the radio, but merely disassociates from the current access point.

> Especially now that iOS 11's wifi-off button in the control center no longer actually disables the radio

I still can’t belive this decision. I keep my Bluetooth and Wi-Fi off as much as possible and it’s now difficult to to as a result of this change is ios11. Really bothers me.

Apple's explanation of why they did this. https://support.apple.com/en-us/HT208086

Thanks, their description is interesting. It’s not quite as bad as I thought.

Just go into Settings and disable it as usual.

Or just place it in Airplane Mode and enable Wifi or Bluetooth selectively. At least that's what I do in iOS 10. I hope it's still possible in 11.

Doesn't airplane mode disconnect the cellular radio?

I really don’t understand why people keep those two off. If you’re not using them they use very little battery at this point; it’s not like it was 10 years ago.

Since Apple keeps detailed usage statistics (from the people who opt in) my guess is they know how common such a behavior is and it’s obviously low enough they don’t think this change is a problem.

I agree with some of the other comments I’ve seen that this probably accomplishes what the user is trying to do (ignoring a Wi-Fi network that’s temporarily behaving poorly) and possibly protecting them (forgetting to turn it back on it running up a huge cell bill). I know I’ve heard complaints from people who accidentally did that a number of times.

I keep it off because as I ride a train it's connecting to every station wifi and losing it just as quick, completely breaking connectivity.

Turn off "ask to join" and it will only connect to known networks.

The station wifi is known though, so when I have a long wait for a train at a station I'm not burning data on YouTube

You can set the known network not to connect automatically. But you can only access that setting when you are in range.

I didn't know about that setting, thanks for the tip. Will definitely come in handy.

I keep it off because of exploits posted in this article.

Faraday cage cases are going to be popular next season.

This is a bad take. If your threat model has you concerned about people who follow you around and exploit your Wi-Fi firmware, you probably shouldn't ever have Wi-Fi on -- or maybe you shouldn't be using a smartphone.

For everyone else, the new behavior allows users to disconnect from bad Wi-Fi in Control Center while improving their battery life in case they forget to turn Wi-Fi back on.

I can.. it makes those buttons much more useful for the common case. e.g. this wifi network isn't working, disconnect.. and not forget to reconnect later. I did that often.

And also being hassled about location services not working, etc.

You can still actually disable both through the settings up, just not with the quick access.

Is it really that difficult to use? C'mon... Just force touch it instead of regular touching and you get the same control as before.

Lots of devices don't support force touch, for example all iPads, and iPhone 5s, 6 and 6plus.

Am I missing something? Force touch doesn't do anything except show a bigger control with all the radio settings. There is no option to disable wifi, you still have to go to the settings.

Does not having to join a network make a big difference for a worm considering the amount of wifi networks we share with large numbers of other people?

I'd say so. Imagine a worm which could spread itself to any phone within WiFi signal range. I'd guess at a worm like that covering a whole city at a really rapid pace. If you're stuck with infecting networks then the main transmission vectors would be offices, homes and cafes/restaurants etc. I think it would be much slower and much less far reaching.

Reply on news.ycombinator.com