>Format specifiers can take extra “arguments”. - "%hhn": store the number of bytes written mod 256 to the char pointer ...
Oh boy. I'll put that down for my "thing I don't think I wanted to know" of the day.
Oh boy. I'll put that down for my "thing I don't think I wanted to know" of the day.
Oh boy. I'll put that down for my "thing I don't think I wanted to know" of the day.
[0] Mentioned (but not directly linked) by TFA:
https://www.usenix.org/conference/usenixsecurity15/technical...
Edit: ok, I'm guessing it's a joke about Turing completeness. Loops, you know.
> To achieve full Turing-complete computation, we need a way to loop a format string. This is possible by overwriting the pointer inside printf() that tracks which character in the format string is currently being executed. The attacker is unlucky in that at the time the “%n” format specifier is used, this value is saved in a register on our 64-bit system. However, we identify one point in time in which the attacker can always mount the attack. The printf() function makes calls to puts() for the static components of the string. When this function call is made, all registers are saved to the stack. It turns out that an attacker can overwrite this pointer from within the puts() function. By doing this, the format string can be looped.
> An attacker can cause puts() to overwrite the desired pointer. Prior to printf() calling puts(), the attacker uses “%n” format specifiers to overwrite the stdout FILE object so that the temporary buffer is placed directly on top of the stack where the index pointer will be saved. Then, we print the eight bytes corresponding to the new value we want the pointer to have. Finally, we use more “%n” format specifiers to move the buffer back to some other location so that more unintended data will not be overwritten.
[0] https://www.usenix.org/system/files/conference/usenixsecurit..., Appendix B "Printf is Turing-complete".
[0] Mentioned (but not directly linked) by TFA:
https://www.usenix.org/conference/usenixsecurity15/technical...
Perhaps a scanner than I can run against all of github, and then rank results by the number of times that code is exposed on a high value server connected to the internet...?
I don’t think it’s worth the effort to extend that to look for tainted strings, not because it wouldn’t be useful, but because it would be hard to do (as an extreme example: is data read from a file user input? It could be a file containing internationalization info)
The (relatively) few programs that construct format strings on the fly will have to add pragmas to disable these warnings.