Quote:
Originally Posted by MaxWilson
Oh, wow. %n does not modify the output from printf but instead treats its arguments are a memory address and sets it to the number of characters printed so far. That raises the threat potential from printing out the contents of your Dom3 process to modifying memory, including the instruction pointer. http://julianor.tripod.com/bc/formatstring-1.2.pdf
It's interesting that vfb reports that this will cause crashes. Maybe Dom3 is compiled in a mode that does stricter checking of printf, and throws an exception if the wrong number of arguments is supplied. In that case it's not a security threat after all.
-Max |
No, I just said %s will cause crashes. I did not think of %n, I was not aware of that actually.
The printf call used does check for a null argument to %s on the stack and prints "(null)" in that case, but it's going to seg fault (crash) if there's something on the stack like a random integer value.
It's impossible to do a compile-time check of the printf arg count when the format string itself is variable. And that's the problem here, the format string should be "%s" instead of the user-entered message.
It's also impossible for a library function like printf to know how many arguments it was actually passed. Whatever is on the stack is just there, and it will try to use it according to the format string.