Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>When you call a function like printf, the formatstring and the arguments are pushed onto the stack. If you ommit the parameters but specify them in the format string with "%x" or "%s" or "%n" you cann access (read or write) the formatstring. On one system i testet that, the format string was the 4th argument. On another it was beyond the 200th.</p> </blockquote> <p>No, perhaps you have misunderstood.</p> <p>When you call printf with one argument - the format string, a pointer to the format string is pushed onto the stack. This is a <code>char *</code> This pointer can point to anywhere in memory - printf just does at it is told and reads that memory location as a format string.</p> <p>In the usual one argument case, you pass a string literal to <code>printf ("hello world!");</code> The compiler puts the text <code>hello world</code> somewhere in memory, and generates a pointer to it to pass to printf. Then it does whatever the calling conventions say it should do for a function call - for example on x86 it pushes the pointer to the stack. Printf then reads its first argument from the stack and is happy!</p> <p>In the usual n argument case, the same thing happens with the string literal and the pointer. For the function call, the compiler passes each of the values. Again using x86 (Because pushing is easier to describe than, say, ARM which has a complicated argument passing scheme) These values are pushed to the stack from right to left. So if you have a call to <code>printf ("%d, %s, %d", x, name, y);</code> y is pushed to the stack, then name, x, and finally the format string.</p> <p>Now, inside printf we read our first argument (get it from the stack). It is a <code>char *</code> pointing to <code>"%d, %s, %d"</code>. We can read this, and then - knowing how the compiler passes arguments we can read the three things which were pushed to the stack - Again we are happy!</p> <p>The format string vulnerability works by misaligning the belief printf has and the belief which the compiler has.</p> <p>We can show it by invoking the undefined behaviour caused by passing the wrong number of arguments to printf. in the call <code>printf ("%s");</code> The compiler does not push the argument which would correspond to the <code>char *</code> printf expects to use to fulfil the <code>%s</code> directive. But - because printf doesn't know the compiler didn't do it it looks for the argument on the stack anyway. It pulls an undefined value off the stack and attempts to read the string it points to.</p> <p>In your case you allow arbitrary format strings to be passed to printf. These certainly have a mismatch between the number of arguments expected and the number of arguments passed, and so printf reads the stack - which is filled with junk.</p> <p>If you are lucky - you can manipulate this junk to point to something you control - and can use this to read information you were not expecting. If you can trick a %n argument to point to somewhere you control, you can write to that memory location with the number of characters printed.</p> <p>So - with this description in mind I can't find a way to parse your question which makes sense. Perhaps you can be more clear and I can update my answer?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload