Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploiting the Wi-Fi Stack on Apple Devices

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Exploiting the Wi-Fi Stack on Apple Devices

#51

Post by KozmoNau7 »

mikeash wrote: post #21
walterbell wrote: post #19

Earlier quoted context omitted.

If you want to avoid cellular charges, shouldn't you be turning off cellular?

The problematic scenario goes like this: 1. You're in a coffee shop. The WiFi sucks today. You turn off WiFi so you can use your cellular connection instead. 2. Many hours later, you go home, having forgotten about #1. 3. You binge-watch the entirety of Doctor Who streaming on your phone, not realizing the phone is still using cellular. 4. Large bill from your provider.

5. Realize you should have gotten a subscription with an adequate data plan.

6. Get said subscription.

7. Stop worrying.

Re: Exploiting the Wi-Fi Stack on Apple Devices

#52

Post by KozmoNau7 »

williamscales wrote: post #30
hdra wrote: post #24

Earlier quoted context omitted.

I want to see the problem solved, but this feels like the wrong solution. Reminds me of the time where I couldn't trust what the UI says about the audio of my desktop computer running Linux circa 2005

Many apps will prompt before doing a large download over data. Spotify has separate settings for mobile data and Wi-Fi streaming quality. One could imagine a video app would prompt before streaming on mobile data. I'm pretty sure this is the solution—perhaps the Android or iPhone media framework itself could implement something that would warn people if app developers are often forgetting to add this feature?

Android even goes too far here. "Download waiting for wifi", for a 20MB download. I use more data than that simply by opening certain apps!

Re: Exploiting the Wi-Fi Stack on Apple Devices

#53

Post by KozmoNau7 »

givinguflac wrote: post #18
deftturtle wrote: post #17

Earlier quoted context omitted.

Apple thinks for its users in all the wrong ways.

Several people in my family have had overage issues by forgetting about WiFi being off. They are certainly not technically inclined.

Get them a subscription with an adequate data plan, then?

Re: Exploiting the Wi-Fi Stack on Apple Devices

#54

Post by Sephiroth87 »

pgeorgi wrote: post #47
planb wrote: post #39

Earlier quoted context omitted.

No, it does not if the Wifi Chipset is disabled, because it uses wifi for location services (GPS would use way too much battery). That's exactly the problem: The wifi chipset is used for much more than just connecting to the internet.

It's exactly what my phone does (Nexus 5X with Android 8), likely by listening to wifi passively ("which SSIDs are around?")

That doesn't sound like a disabled chipset...

Re: Exploiting the Wi-Fi Stack on Apple Devices

#55

Post by e12e »

Moter8 wrote: post #48
mankash666 wrote: post #4

Wonder if something like this was used to get into the San Bernardino shooter's phone by the FBI

Cellebrite got into that phone. A presenter from the firm told us so. Apparently 300 devs work fulltime on mobile devices in Isreal to develop iOS/Android exploits, mostly for Law Enforcement or despots. He talked quite a bit about what you can get off the devices, but not much on the how to get into there. Apparently Android-encrypted phones are the safest though. They didn't have an exploit for them 2 months ago.

> Apparently Android-encrypted phones are the safest though.

That's odd. I guess the implication is that iPhone hsm is broken (or they can get past a short pin via an exploit that allows brute forcing - typically an hsm should (be possible to configure to) permanently destroy the keys after N attempts).

I suppose it demonstrates that secure encryption requires the user to memorise something equivalent of 96-128 bits of entropy, that will be used for key derivation.

[ed: i suppose it's conceivable that there's an attack against how the iPhone generates symmetric encryption keys, but I would guess that's less likely]

Re: Exploiting the Wi-Fi Stack on Apple Devices

#56

Post by e12e »

ksec wrote: post #35
senatorobama wrote: post #28

When will Apple dump Broadcom?

But Why? Not until Apple make their own WiFi Chip ( Which they are doing with W1 in Airpod and W2 in Apple Watch ) But until then Broadcom still has the best WiFi Chip. Qualcomm Atheros is a big no no.

> Qualcomm Atheros is a big no no

Sarcasm? If not, care to elaborate?

Re: Exploiting the Wi-Fi Stack on Apple Devices

#57

Post by rospaya »

TheSpiceIsLife wrote: post #34
Cyph0n wrote: post #27

Earlier quoted context omitted.

Why thank you! I would truly be lost without your wisdom. Unfortunately, that still doesn't explain Apple's decision to make it harder to switch off WiFi. Do iPhone users simply not notice the status bar?

I'm not defending nor evangelising Apples current solution. I'm lead to believe it's not iPhone users specifically, but people in general. I've worked in IT, but qualified as a tradesmen nearly a decade before, and I occasionally forget to turn wifi back on when I get home. I currently work for a large steel fabrication company. One of the project managers here doesn't even use email . It's way too easy for the avera…

In 5 years we're gonna wonder how we got to the point where you can't easily turn off wifi, slowly dumbing down devices for all of us for the sake of your project manager and the like.

Re: Exploiting the Wi-Fi Stack on Apple Devices

#58

Post by TheSpiceIsLife »

Cyph0n wrote: post #36
TheSpiceIsLife wrote: post #34

Earlier quoted context omitted.

I'm not defending nor evangelising Apples current solution. I'm lead to believe it's not iPhone users specifically, but people in general. I've worked in IT, but qualified as a tradesmen nearly a decade before, and I occasionally forget to turn wifi back on when I get home. I currently work for a large steel fabrication company. One of the project managers here doesn't even use email . It's way too easy for the avera…

A better way would be to: (1) use either GPS or cell towers to specify some sort of geographical area (with user input of course), and then (2) allow the user to specify what happens to WiFi/3G when entering and/or exiting that area. Llama on Android has been doing this for years, but the UX was a mess in my opinion. Apple could streamline the setup process, throw in some "amazing"s and "revolutionary"s, mix that wit…

It does sadden me there aren't a bunch more advanced options a level or two below the standard options on iPhones.

I didn't down vote you by the way.

Re: Exploiting the Wi-Fi Stack on Apple Devices

#59

Post by rhexs »

bitexploder wrote: post #20
js2 wrote: post #3

I'd love to know how many hours were needed to develop this exploit from start to finish, and how many dead ends the researcher ran into along the way. Just writing the blog post and generating all the images for it must've taken many days.

I have followed iOS JB for years and keep up with exploit dev and mitigation/defense. The usage of source code and avoiding deep assembly documenting helped a lot. You are still looking at several man days of deep work on understanding the driver and stack. KASLR was the only real mitigation to bypass. That could have been a difficult part worth it's own discussion. Bypassing ASLR typically requires an info leak. I t…

Goodness, it takes only several days to reverse engineer a driver and stack now? Wow. I know the project zero guys are good, but damn.

Re: Exploiting the Wi-Fi Stack on Apple Devices

#60

Post by mikeash »

hdra wrote: post #24
mikeash wrote: post #21

Earlier quoted context omitted.

The problematic scenario goes like this: 1. You're in a coffee shop. The WiFi sucks today. You turn off WiFi so you can use your cellular connection instead. 2. Many hours later, you go home, having forgotten about #1. 3. You binge-watch the entirety of Doctor Who streaming on your phone, not realizing the phone is still using cellular. 4. Large bill from your provider.

I want to see the problem solved, but this feels like the wrong solution. Reminds me of the time where I couldn't trust what the UI says about the audio of my desktop computer running Linux circa 2005

I think they're close to a good solution but not quite there. A tri-state button, where it's on/on-but-disconnected/off might have done it, or at least some indicator that "off" doesn't mean off.
Post reply on HN