Format string bugs, you’d think we’d be done with them by now, but Shielder here documents one in ASUS routers.

I feel like the blame for this one might just come down to a developer not recognizing that syslog itself supports printf-style format specifiers on its own. The code within the logmessage_normal function will first resolve all the format specifiers into a buffer using a vsnprintf call, and this it will call syslog with the resultant buffer.

This means that any user-input that gets “safely” printed into the buffer to be logged will be interpreted again when it passes through syslog. And of course, as we already spoiled one can indeed included data that gets logged through teh rc_service field of the JSON that gets parsed from the web by do_set_iperf3_srv_cgi/do_set_iperf3_cli_cgi.

As the binary was not compiled as position independent executable there were corruption targets that were not randomized by the base ASLR of the system.. They were able to use the format string attack to target the SystemCmd global variable that is used by sys_script and passed into system(). Then by triggering any function that used sys_system their command would be executed.

Unfortunately, in their emulated device the inital format string bug was accessible, in practice on actual devices however this would be impossible to reach, but its still a fun bug and I appreciate their look at exploiting this from a data-only perspective instead of the traditional format string attacker strategy of overwritting a GOT entry and ROP.