Bug in iOS can break iPhone Wi-Fi using rogue hotspot name

Posted:
in iOS edited June 19
A bug has been discovered in iOS that can disable an iPhone's ability to connect to Wi-Fi hotspots, if it attempts to initially connect to a hotspot with a specific name that breaks the function.




Security researcher Carl Schou gave a personal Wi-Fi hotspot a name of "%p%s%s%s%s%n." On trying to connect to the hotspot, Schou discovered the iPhone simply couldn't connect to it at all, and later discovered that it disabled Wi-Fi connectivity completely on the device.

Attempts to connect to other hotspots failed, with the issue continuing to mainifest after changing the hotspot's SSID and rebooting the iPhone, according to BleepingComputer. The issue was also confirmed by others testing out the same SSID name separately.

After joining my personal WiFi with the SSID "%p%s%s%s%s%n", my iPhone permanently disabled it's WiFi functionality. Neither rebooting nor changing SSID fixes it :~) pic.twitter.com/2eue90JFu3

-- Carl Schou (@vm_call)


Tests also point to it being a problem just with iPhones, as Android devices appear to connect to the unusually-named access point without issue.

Other researchers examining the phenomena believe it is an issue with input parsing, in that the percentage sign at the start may be misinterpreted by iOS as a string-format specifier, in that characters following may be a variable or a command rather than plain text.

To fix the problem on affected iPhones, users have to reset their iOS network settings.

How to reset network settings in iOS

  • Open Settings
  • Select General then Reset
  • Select Reset Network Settings
  • Confirm the request.
  • Once the iPhone has restarted, set up your Wi-Fi as normal.
The discovery is reminiscent of text messages that contained strings and special characters that could cause problems for iPhones and iPads. For example, April's "text bomb" forced iPhones to crash if a flag emoji and a specific Sindhi language character were viewed in an incoming notification.

Keep up with everything Apple in the weekly AppleInsider Podcast -- and get a fast news update from AppleInsider Daily. Just say, "Hey, Siri," to your HomePod mini and ask for these podcasts, and our latest HomeKit Insider episode too.If you want an ad-free main AppleInsider Podcast experience, you can support the AppleInsider podcast by subscribing for $5 per month through Apple's Podcasts app, or via Patreon if you prefer any other podcast player.AppleInsider is also bringing you the best Apple-related deals for Amazon Prime Day 2021. There are bargains before, during, and even after Prime Day on June 21 and 22 -- with every deal at your fingertips throughout the event.

Comments

  • Reply 1 of 11
    I wonder what would inspire a researcher to come up with ‘let’s try %p%s%s%s%s%n‘?
    williamlondonItsDeCiacaladanian
  • Reply 2 of 11
    davidwdavidw Posts: 1,328member
    techrider said:
    I wonder what would inspire a researcher to come up with ‘let’s try %p%s%s%s%s%n‘?
    It seems that "%p%s%s%s%s%n" was the actual name of a WiFi hotspot he set up. Not something he randomly entered into his iPhone, on the whim. And it would seem that any WiFi name that starts with a "%" would have triggered the bug. So he would had gotten the same result with something like "%MyHotspot"

    What i'm wondering is whether the WiFi name showed up under the list of WiFi available to join or did he have to manually enter that WiFi name under "join other network"?  If I set up a WiFi network named "%FreeWiFi", would it disable the iPhone  WiFi of unsuspecting iPhone users that tried to join because they were tempted by the name to select it from the list of available WiFi networks in the area?  
    edited June 19 caladanian
  • Reply 3 of 11
    I'm surprised this isn't attracting more attention. This is an awful bug, and quite possibly a privilege escalation vulnerability, once someone figures out how to use it.

    The article calls it a "strong-format" specifier. It's really a "string format" specifier, and the fact that this bug exists at all is just a terrible failure. It means the code isn't doing input sanitization on WiFi names. The fact that it crashes WiFi until network settings are reset likely means that it's causing an overflow that trashes the plist. (Similar problems have existed in MacOS in years past, though due to other causes.) There may be memory corruption as well.
    elijahgbeowulfschmidt
  • Reply 4 of 11
    lkrupplkrupp Posts: 9,452member
    Yaaawnn...
    williamlondonmacplusplus
  • Reply 5 of 11
    elijahgelijahg Posts: 2,311member
    lkrupp said:
    Yaaawnn...
    Why is this "yaaawnn"? Think Apple bugs shouldn't be reported because it makes them look bad or some crap? If this was an Android or Windows bug no doubt you'd be "HAHA shit Google/MS programmers!!" Some apologists here really are insufferable.
    muthuk_vanalingam
  • Reply 6 of 11
    lkrupplkrupp Posts: 9,452member
    elijahg said:
    lkrupp said:
    Yaaawnn...
    Why is this "yaaawnn"? Think Apple bugs shouldn't be reported because it makes them look bad or some crap? If this was an Android or Windows bug no doubt you'd be "HAHA shit Google/MS programmers!!" Some apologists here really are insufferable.
    It wouldn’t whose bug it was. This bug is a big yaaawwn, a nothing bug, an irrelevant bug 
    williamlondonmacplusplus
  • Reply 7 of 11
    elijahgelijahg Posts: 2,311member
    lkrupp said:
    elijahg said:
    lkrupp said:
    Yaaawnn...
    Why is this "yaaawnn"? Think Apple bugs shouldn't be reported because it makes them look bad or some crap? If this was an Android or Windows bug no doubt you'd be "HAHA shit Google/MS programmers!!" Some apologists here really are insufferable.
    It wouldn’t whose bug it was. This bug is a big yaaawwn, a nothing bug, an irrelevant bug 
    If you were less ignorant, you'd understand that it's symptomatic of a deeper issue; the non-sanitisation of an input to the OS. The same vectors malicious actors use to access parts of RAM they shouldn't, and ultimately access passwords, install malware etc. So it could quite easily end up a much bigger bug that is exploitable by North Korea, Russia, NSA etc. These kind of input-sanitisation bugs are pretty rare nowadays in most OSs, but Apple in particular seems prone to forgetting to clean up user inputs.
    edited June 19 CelticPaddyFileMakerFeller
  • Reply 8 of 11
    Rayz2016Rayz2016 Posts: 6,957member
    lkrupp said:
    elijahg said:
    lkrupp said:
    Yaaawnn...
    Why is this "yaaawnn"? Think Apple bugs shouldn't be reported because it makes them look bad or some crap? If this was an Android or Windows bug no doubt you'd be "HAHA shit Google/MS programmers!!" Some apologists here really are insufferable.
    It wouldn’t whose bug it was. This bug is a big yaaawwn, a nothing bug, an irrelevant bug 
    That’s the spirit. ߙ䦬t;br>

    The bug shuts down a key part of the iOS software stack but, believe it or not, that’s not the serious part. 

    A few years ago, I tried to explain (and was shot down in flames) why having iOS reset itself by sending it a text message with weird characters pointed to a serious problem with the way Apple develops and tests software. 

    They fixed the problem. 

    A few months later, a different text message with weird characters shut down iOS. 

    Now, if you’d spent any time working in QA, the occurrence of the first problem would strike you as problematic. When it occurred again, that would tell you that they didn’t fix it the first time: they just did some sloppy patch to specifically trap instances of the first occurrence. 

    And now here it is again. The same occurrence of a perfectly valid but odd string making its way through the stack until reaches a point where it can do some damage. 

    Som at the risk of being shot down again, I’m going to say it again: there is a serious problem with the way Apple develops and tests code if these first-time-coder errors are slipping through. 

    And one of these bugs is going to cause a serious breach one day unless they get a grip on it. 

    I wonder if the same person who codes Apple’s string checking is the same person who wrote the post editor for this site. 
    edited June 20 elijahgmuthuk_vanalingambeowulfschmidtFileMakerFellerjony0
  • Reply 9 of 11
    charlesncharlesn Posts: 173member
    Rayz2016 said:

    Som at the risk of being shot down again, I’m going to say it again: there is a serious problem with the way Apple develops and tests code if these first-time-coder errors are slipping through. 
    Clearly, Rayz, you should be spending less time on the AI forum boards and more time pitching yourself to Tim Cook as the guy to fix Apple's sloppy coding. Please DO stop back here and let us know how that goes!
    williamlondon
  • Reply 10 of 11
    markbyrnmarkbyrn Posts: 646member
    I tested this out myself and sure enough, the WiFi broke BUT as soon as I turned the %p%s%s%s%s%n Hotspot off, it fixed itself with no need to reset the network settings. Funny how Bleeping didn't bother to mention.  It's really a nothing burger but thanks to Bleeping, you'll have immature Android types setting up these hotspots at public spaces to get nothing more than malicious giggles.  
    williamlondonwatto_cobra
  • Reply 11 of 11
    techrider said:
    I wonder what would inspire a researcher to come up with ‘let’s try %p%s%s%s%s%n‘?
    There's an article on Art Technica that explains this. He routinely tries potentially troublesome names for network devices to see what breaks - mostly it's older tech, but in this case it's a modern OS subsystem.

    For this particular bug, it's only affecting the process that writes to a log file. But Elijahg and Rayz2016 are correct: it's yet another instance of Apple software not checking the data inputs properly, and that is HUGELY serious. A few months ago there was another bug of similar type in macOS; GateKeeper failed to check for the presence of certain files within an app bundle and thus allowed a shell script file to run SILENTLY - no check for notarisation, no scan for malicious code, NOTHING. This (long) article has more details: https://www.objective-see.com/blog/blog_0x64.html

    Frankly, for a company as committed to security as Apple is, it's not good enough. This is a systemic, recurring pattern of behaviour. The toolchain needs to be updated to routinely check for this sort of thing, and every programmer in the company needs to undergo mandatory secure coding training. Delay the annual OS cycle - the stuff announced at WWDC this year isn't all going to be ready for release at the official ship date, so take advantage of that to make these changes. Delay stuff until next year's release if you have to - people have been clamouring for more stable software anyway.

    JUST.GET.IT.FIXED.
Sign In or Register to comment.