A specific network name can completely disable Wi-Fi on your iPhone | Hacker News Reader

A specific network name can completely disable Wi-Fi on your iPhone

9to5mac.com

106 pointslaktak58 comments

"The Wi-Fi subsystem probably passes the Wi-Fi network name (SSID) unsanitized to some internal library that is performing string formatting, which in turn causes an arbitrary memory write and buffer overflow. This will lead to memory corruption and the iOS watchdog will kill the process, hence effectively disabling Wi-Fi for the user."

This sounds like a significant security bug?

It’s pretty significant but a strong mitigating factor is that you have to join the network manually before this happens.

Surely more of a mitigating factor is that there's nothing to 'do' with it afterwards? It's easy to get people to (try to) join your WiFi network, but then what? Without some serious secondary effect I'd guess it's probably not getting desperately quick attention or a big payout.

With arbitrary memory writes, and an apparently reliable form of persistence across reboots, there's a pretty good chance there is something to do with it afterwards (RCE, leading to control of wherever this runs)... it sounds like that part just hasn't been figured out yet.

Format strings can do arbitrarily memory reads/writes so this will probably quickly turn into an RCE bug (it likely already has but we won't hear for another 90 days unless someone very based decides to tell us.)

I get reads, but writes? How do you manage that? I'm presuming they're using the safe versions of sprintf but in case they're not, they probably have bigger problems.

I think printf has a %n specifier that writes the number of characters so far to a pointer passed in.

This was true maybe 10ish years ago ago but with ASLR, PAC, stack cookies and other mitigations it is now much harder to turn even a legitimate vulnerability (like a trivial buffer overflow) into actual RCE. Theres every likelihood that this isn't actually exploitable, on the other hand it might be, we will have to wait and see.

Seems like an annoying DoS bug for sure. This is why having an actually secure watchdog is so nice. I still don't understand why people jailbreak in 2021.

So they can sideload apps not approved by the Apple App store. A feature that Android phones have when developer mode is on.

Can do that without a jailbreak though https://altstore.io/

You have to trust them with your Apple ID (from the FAQº):

Why do you need my Apple ID?

Apple allows anyone with an Apple ID to install apps they’ve built themselves onto their devices for testing. AltStore uses your Apple ID to communicate with Apple's servers on your behalf and perform the necessary steps to prepare your account for installing apps onto your device.

Do you save or send my Apple ID to anyone besides Apple?

Your Apple ID is never sent to anyone but Apple. AltStore does save your Apple ID so it can refresh apps for you automatically, but it is stored securely in the device’s keychain. AltServer does not save your Apple ID, and requires you to enter your credentials each time.

(Ofcourse, Jailbreak isn't necessarily more secure - you have no idea if they inject a malware into your device during the process.)

º https://altstore.io/faq/

It’s such an obvious class of bug that any decent compiler complains if you do the equivalent of

    printf(theStr);

rather than

    printf(“%s”, theStr);

Still this bug regularly crops up all over the place, making the % character risky when naming any shared resource.

Little Bobby printf.

https://bobby-tables.com/

"unless a load of Wi-Fi pranksters suddenly pop up in the wild with open Wi-Fi networks using the poisoned name"

Heh. I do appreciate the subtlety here.

Literally the only thing stopping this from causing mass havoc is that most cafes are closed because of covid. If they were open you can cause quite a lot of grief by programming a bunch of esp8266 with this exploit and dropping them off at random cafes with a battery pack.

lol "mass havoc" when we're dloading 80mbps over cellular connections...

It seems to effectively brick your wifi in a way that survives power cycles, deleting the SSID, etc. The only thing that unbricks it is General -> Reset -> Reset Network Settings. So perhaps not havoc, but it would be pretty annoying.

Yes, good going - I think somebody just gave Woz a idea there ...

Strong sense of dejavu. We used to send crash text messages to each other's iphones for fun. And the wifi has a vulnerability for names as well?

Lessons will be repeated until they are learned.

(Un-)fortunately, just photographing a QR code(0) with the mentioned SSID does not work ("Unable to join the network "%p%s%s%s%s%n").

Don't have a quick way to setup a WiFi with the specific SSID ATM. Would be interested to see if that works.

0: https://qifi.org

Did you actually set up a WiFi network with that name first, for it to connect to though?

earlier post: https://news.ycombinator.com/item?id=27560438

Most Linux/BSD distros compile their binaries with compiler hardening flags that mitigate this sort of issue, does Apple not use those flags?

I know what my new guest network will be called....

why are percentage symbols even allowed in wi-fi network names?

Yet another reason why C was a mistake.

Parsing unstruted strings without escaping special characters is an issue in any language. This is completely Apple's fault.

Funny how these faults keep happening over and over again in the same set of languages.

I am pretty sure that I can have injection attacks from unsanatized user inputs in any language.

Yes, but some languages (like my personal favorite Rust) make it practically impossible to happen with their equivalent of printf().

Funny how most car crashes are caused by humans driving.

We've all been trained to sanitize user input, but the WiFi SSID isn't a user input string, so why should I need to sanitize it? --some poor dev wondering where their Twitterverse sympathy is

Yeah it is, I can definitely type my SSID in any device that I have.

I'm typing a new SSID in right now...

In a better language than C, format string injection would be less likely to lead to arbitrary read/write/RCE.

I'll admit I looked around before writing this and saw that Python's str.format() can be pretty bad. So let's say a reasonably constrained formatting language in a good runtime -- the attacker is limited in what they can see or control, and the formatter can see how many arguments were actually passed so it doesn't tromp off into other memory.

You are making a false equivalence—not all languages are equally busted. Any sanely designed modern language does not allow this to happen. Accidentally parsing a string you didn’t mean to parse is a fault of C’s outdated API design, a design flaw that keeps tripping people up again and again.

> Any sanely designed modern language does not allow this to happen

Sorry, how does Rust protect you against injection again?

Why would Rust do anything weird when presented with the string "%p%s%s%s%s%n"?

Why would C?

Do you want the obvious explanation? Because the string was passed into the format string parameter of some sprintf-like, a common mistake in C usually caught by warnings but seemingly ignored or suppressed in this case.

edit: turns out from the analysis it was CFStringCreateWithFormatAndArguments, so yes, a sprintf-like used incorrectly

This is possible with any language. Not just C.

No, Rust for example explicitly disallows this.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

You miss my point entirely.

What is your point then?

You can do this in any language. Rust doesn't support it with PrintLn but it's still possible with Rust. Stop acting like C did anything wrong.

By requiring format strings to be literals.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

It's completely their fault either way. They are responsible for the technology they use.

This nasty printf()-like way of formatting is a giant footgun though. Apple are not the first ones to fall into this trap.

Oof. I hate to call C a mistake. I hold the language close to my heart; quirks and all.

Sure there are safer models for computing. But it has served its purpose for a long time. A small language allowing highly performant programs/operating systems to be written. Plus we got to see the beautiful art form of exploit writing. Sure at what cost (lots), but all hackers can appreciate when a system gets owned. It’s the intentions that come after which bother us all.

Don’t get me wrong, I’m excited for newer languages like rust to come along. However, I learned so much about low level computing from c, and I’m forever grateful.

Hats off to Dennis Ritchie. Thanks for creating a language I met so many other hackers through, and sparking the curiosity of hacking within me.

I would like to see Rust run on a PDP-8.

But it doesn't need to, and we are talking about a modern system.

C was great for its time, now its time to move on and use a sensible language.

Are Apple using C for this level of subsystem? I thought a lot was in Objective-C or is that just higher level stuff?

Apple uses C for some bits.

Also there are Objective C APIs which take format strings, like +[NSString stringWithFormat:] and the system function NSLog().

Even Swift uses format strings in places. https://developer.apple.com/documentation/swift/string/31267...

C wasn't a mistake. It used to be very popular for a reason. Just like steem locomotives, they served their purpose very well in their time, but the world has moved on.

This could also be an intentional thing put into iOS to force an iPhone off Wi-Fi so it will connect to a Stingray device so traffic can be intercepted.

No, because it requires you to have physical access to connect to it. If you have physical access, you could just turn off WiFi at that point.

If you think that someone targeted would notice their WiFi turned off and turn it back on, they would definitely notice and probably become suspicious of that behavior shown in the video where WiFi automatically turns itself on and off rapidly.

They would need to know they're being targeted for them to be suspicious. Most people would see that happen and assume either a software bug or the screen had gotten wet.

That said, I also find it unlikely this is a planned exploit.

It's probably cheaper and easier just to jam the Wi-Fi bands than to try this trick.

Reply on news.ycombinator.com