It's 2021 and a printf format string in a wireless network's name can break iPhone Wi-Fi Joining a Wi-Fi network with a specific sequence of characters in its SSID name will break wireless connectivity for iOS devices. Thankfully the bug looks to be little more than an embarrassment and inconvenience. On Friday, Carl Schou, a security researcher in Denmark, reported that his iPhone lost its Wi-Fi capability after …
At first glance I thought it had read "%p%o%i%s%o%n". (I'm surprised the investigators didn't try that)
Somehow I think that SSID name would also get lots of attempts by the same people who'd try "FBI Surveillance Van".
I also think a lot of people will also be (temporarily) changing SSID names just to poke the iPhone fans.
The NSString documentation isn't clear on what parts of the printf spec it supports. If it supports padding to 2000000000 characters, it just might do some damage.
(Browsing through code samples reminds me that dropping MacOS development from my career because of Objective C was a good call)
For reasons strongly related to the word 'coffee'.
Hot brown fluid that may or may not have originated in the vicinity of a ground coffee bean, and weirdly and liberally adulterated with non-coffee flavourings, would be a more fitting description.
does it make sense to parse an SSID as a scanf specifier?
I. DO. NOT. CARE. if this can be exploited or not. This is like the systemd random fiasco. It is an utter failure of the most basic rules of programming that it calls into question any claims relating to the platform at all.
Not an excuse but an observation.
The Apple documentation for NSString shows that it has about 30 gazillion methods, and calls onto Core Foundation code for some of its functionality - and the bug could be in any of the code because, as a developer, you have no idea which methods call what without installing a debugging version of the NSString library and stepping through it all yourself.
OO programming was supposed to simplify things: it seems to have stopped doing that.
Anything that encourages more code reuse also encourages not knowing exactly what the code you constantly reuse does behind the scenes. Like many things, its a tradeoff.
At least one thing in the "favorable" column of the tradeoff is that if a bug is discovered in code that is reused in many places, it only needs to be fixed once. If everyone is reinventing the wheel, many bugs will need to be fixed over the years.
Just tried to create an open hotspot named "R%s%s%s" on my Android. The iPhone 8 (14.6) sitting next to it does not auto-connect to it. When trying to connect manually the iPhone says "Unable to join the network" and then WiFi turns itself off and cannot be turned back on again until the iPhone is restarted.
So much for the apple store idea. If you could get it to auto-connect then this could indeed wreak havoc in the turtle-neck department.
I have Auto Join = Ask, and Ask To Join = Notify, so I don't join strange networks. There was an episode of Doctor Who where you do that and the wifi eats you or something.
Since I encountered something called Wifi Max I think which auto joins anyway, I usually turn off wifi when I'm out.
Famous last words?
It does sound very unlikely that this might be an actual security vuln, but then so many previous ones have also been "very difficult or impossible" to exploit too. Especially when one exploit is linked to others. Maybe some hacking group or TLA out there is going "Oh crap, that was one of our better ones too!"
Try this on a little endian machine. It shouldn't do anything bad, but might give a hint about exploitable....
```
#include <stdio.h>
main() {
char targ[100] = {0};
FILE *fp = fopen("/dev/null", "w+");
fprintf(fp, "%1953460082.1953460082s%n", "", targ);
fclose(fp);
printf("%s\n", targ);
}
```
Anyone who makes WiFi low-level software: this is one to add to your automated test suites, please. Pretty please.
(Shameless plug: unless, of course, you use Ada to write your critical software :-)
(You know, the International Standard programming language that was _designed_ for writing safety-critical software.)
(And even then, of course, still add it to your automated test suites, since even Ada software has to call into stuff sometimes.)
How many times is Apple going to deny stupid security holes then have to admit to them later?
Like how you used to be able to log into any macbook with full admin privileges by putting a blank username/password and simply rapidly hitting enter?
Or how putting file://// into their text editor would crash the entire system and make it reboot as admin
Or how "typing too fast" would cause the mac to simply give up and change the current token to admin?
etc etc
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
