I am investigating a format string vulnerability on arm64 (linked against musl libc), and am encountering some odd behavior while debugging the output.
From the decompilation, the program has a classic format string vulnerability that boils down to:
fprintf(stdout, user_controlled_data);
Using repetitive format specifiers (e.g. %p%p%p%p
), I can dump massive swaths of memory by including thousands of these characters. That works as expected.
The problem arises when I try direct parameter access. For some reason, %1$p
works but not %2$p
, but 3 up to about 12 works, and everything I've tried after that fails. By "fails", I mean no values are printed, except the newline automatically added to my string earlier in code is eaten somehow. In the debugger, fprintf
returns -1, and errno
is set to 0x16, which I believe is EINVAL.
For this particular scenario, I need the ability to read/write a particular stack offset in the thousands. But I cannot print it to confirm since direct parameter access does not work. I can see the target parameter by using repeated characters, but I need direct parameters to work going forward due to other constraints.
Now, I understand this is in "undefined behavior" territory, but I compiled a vulnerable test binary (statically linked against Glibc, I should probably try against musl) on the system that works as expected with no issues (e.g. %9000$p
prints something).
Is there something that would cause this behavior, or something I am missing? I can provide further information if needed.