CodeColorist
Quick Analysis for the SSID Format String Bug

Quick Analysis for the SSID Format String Bug

Days ago a twitter post revealed a bug in iOS Wi-Fi service:

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) June 18, 2021

Looks like it's a format string bug, which is rarely seen nowadays.

Now set up a hotspot with the same SSID and use my test device to join, the wifid crashes soon.

Here's the symbolicated crash report wifid-2021-06-20-xxxxxx.ips

So it's really a format string bug!

Decompile this function -[WFLogger WFLog:message:] in dyld_shared_cache. There are two references to CFStringCreateWithFormatAndArguments.

Another one

Debugging this issue with lldb will be painful because this method hits too often. Instead, attach frida to it: frida-trace -U wifid -m '-[WFLogger WFLog:message:]' and modify the auto-generated script a little:

Here's the log right before the crash.

17863 ms -[WFLogger WFLog:0x3 message:Dequeuing command type: "%@" pending commands: %ld]

17863 ms -[WFLogger WFLog:0x3 message:{ASSOC+} Attempting Apple80211AssociateAsync to %p%s%s%s%s%n]

According to the backtrace, this is the root cause:

It concats the SSID to a format string and pass it to WFLog:message: method. Destination is 3 so it was the second xref of CFStringCreateWithFormatAndArguments that triggered the denial of service.

Update: by the time of writing, NULL-isa was still a thing. So probably it was exploitable.