format string vulnerability problem

[tom]

Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
#include <stdlib.h>

int main(int argc, char *argv[]){
char text[1024];
static int testVal = -72;

if(argc < 2){
printf("Usage: %s <text\n", argv[0]);
exit(0);
}
strcpy(text, argv[1]);

printf("Right way: \n");
//right way to print
printf("%s", text);
printf("\nWrong way:\n");
//wrong way to print
printf(text);

printf("\n");

//debug
printf("\n[*] testVal @ 0x%08x = %d (0x%08x)hex \n", &testVal, testVal,
testVal);

exit(0);
}

Im trying to overwrite testval:
../fmt_vuln `printf "\x20\x97\x04\x08"`%x.%x.%x%n
Right way:
%x.%x.%x%n
Wrong way:
bfbfe748.b7ff3de7.b80016a4
[*] testVal @ 0x08049720 = -72 (0xffffffb8)hex
Know somebody why didn't it work?
Thanks for answers.
--
TP

[Eric Sosman]

tom wrote:

Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
[... much undefined behavior snipped ...]
Know somebody why didn't it work?

Because undefined behavior is "undefined." The C language
makes no guarantees at all about what your code will do, so it
is silly to expect an explanation of its behavior in terms of C.
The behavior may make sense in terms of a specific implementation
of C, but (1) you didn't reveal what implementation you used and
(2) even if you had, nobody would care much.

If this Erickson states that your broken program "will"
behave in thus-and-such a way, he's wrong.

--
Eric Sosman
es*****@acm-dot-org.invalid

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

tom wrote:

Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
#include <stdlib.h>

Don't forget to include <stdio.hand <string.h>.

int main(int argc, char *argv[]){
char text[1024];
static int testVal = -72;

if(argc < 2){
printf("Usage: %s <text\n", argv[0]);
exit(0);
}
strcpy(text, argv[1]);

If you're looking to cause problems, why not just overflow the buffer
here? If you already tried that earlier, and figured out how that
works, you should really fix this part of the code now.

printf("Right way: \n");
//right way to print
printf("%s", text);
printf("\nWrong way:\n");
//wrong way to print
printf(text);

printf("\n");

//debug
printf("\n[*] testVal @ 0x%08x = %d (0x%08x)hex \n", &testVal, testVal,
testVal);

testVal is never modified after initialisation, so it makes sense for
some compilers to just load a constant here, rather than re-reading
the variable.

exit(0);
}

Im trying to overwrite testval:
./fmt_vuln `printf "\x20\x97\x04\x08"`%x.%x.%x%n

As far as standard C is concerned, the behaviour is undefined.
Different implementations will behave differently. Even on a specific
system, the exact behaviour will likely depend on your compiler's
optimisation level and other compiler options. For example, some
systems provide built-in protection against exactly these sorts of
attacks.

[tom]

Eric Sosman wrote:

tom wrote:

>Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
[... much undefined behavior snipped ...]
Know somebody why didn't it work?

Because undefined behavior is "undefined." The C language
makes no guarantees at all about what your code will do, so it
is silly to expect an explanation of its behavior in terms of C.
The behavior may make sense in terms of a specific implementation
of C, but (1) you didn't reveal what implementation you used and
(2) even if you had, nobody would care much.

(1) $ uname -a
Linux a03-0634b 2.6.16.9 #2 Mon Jun 19 00:29:11 CEST 2006 i686 GNU/Linux
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx-debug
--enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)

Is any possibility to try it. In Erickson's book isn't mention about
compiler, or C implemenatation. Only about OS, gentoo.

If this Erickson states that your broken program "will"
behave in thus-and-such a way, he's wrong.

Thanks.

--
S pozdravem Tomás Pelka

[tom]

Harald van Dijk wrote:

tom wrote:

>Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
#include <stdlib.h>

Don't forget to include <stdio.hand <string.h>.

fixed

>int main(int argc, char *argv[]){
char text[1024];
static int testVal = -72;

if(argc < 2){
printf("Usage: %s <text\n", argv[0]);
exit(0);
}
strcpy(text, argv[1]);

If you're looking to cause problems, why not just overflow the buffer
here? If you already tried that earlier, and figured out how that
works, you should really fix this part of the code now.

It is universal source code, not only for writing. See
http://www.acm.uiuc.edu/sigmil/talks...ormat_strings/,
item 4.

>

>printf("Right way: \n");
//right way to print
printf("%s", text);
printf("\nWrong way:\n");
//wrong way to print
printf(text);

printf("\n");

//debug
printf("\n[*] testVal @ 0x%08x = %d (0x%08x)hex \n", &testVal, testVal,
testVal);

testVal is never modified after initialisation, so it makes sense for
some compilers to just load a constant here, rather than re-reading
the variable.

>exit(0);
}

Im trying to overwrite testval:
./fmt_vuln `printf "\x20\x97\x04\x08"`%x.%x.%x%n

As far as standard C is concerned, the behaviour is undefined.
Different implementations will behave differently. Even on a specific
system, the exact behaviour will likely depend on your compiler's
optimisation level and other compiler options. For example, some
systems provide built-in protection against exactly these sorts of
attacks.

How can i detect this protection?

Thanks for explanation.

--
TP

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

tom wrote:

Harald van Dijk wrote:

tom wrote:

Im trying to overwrite testval:
./fmt_vuln `printf "\x20\x97\x04\x08"`%x.%x.%x%n

As far as standard C is concerned, the behaviour is undefined.
Different implementations will behave differently. Even on a specific
system, the exact behaviour will likely depend on your compiler's
optimisation level and other compiler options. For example, some
systems provide built-in protection against exactly these sorts of
attacks.

How can i detect this protection?

Thanks for explanation.

>From a program, you cannot and should not reliably detect such

protection. As the user, read your system's documentation.

[Mark McIntyre]

On Sun, 11 Feb 2007 16:46:46 +0100, in comp.lang.c , tom
<to******@atlas.czwrote:

>Eric Sosman wrote:

>tom wrote:

>>Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
[... much undefined behavior snipped ...]
Know somebody why didn't it work?

Because undefined behavior is "undefined." The C language
makes no guarantees at all about what your code will do, so it
is silly to expect an explanation of its behavior in terms of C.

>The behavior may make sense in terms of a specific implementation
of C, but (1) you didn't reveal what implementation you used and
(2) even if you had, nobody would care much.

snip details of his implementation

>
Is any possibility to try it.

Did you notice (2) above? The reason Eric mentioned this is because
CLC discusses portable standard C. Your code fragment is incorrect,
broken and nonportable.

>In Erickson's book isn't mention about
compiler, or C implemenatation. Only about OS, gentoo.

I would suggest you throw the book away, or ask the author to explain.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Sun, 11 Feb 2007 16:56:00 +0100, in comp.lang.c , tom
<to******@atlas.czwrote:

>Harald van D?k wrote:

>tom wrote:
As far as standard C is concerned, the behaviour is undefined.
Different implementations will behave differently. Even on a specific
system, the exact behaviour will likely depend on your compiler's
optimisation level and other compiler options. For example, some
systems provide built-in protection against exactly these sorts of
attacks.

How can i detect this protection?

Why would you want to? Its there to protect you and your customers.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

tom <to******@atlas.czwrites:

Eric Sosman wrote:

>tom wrote:

>>Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
[... much undefined behavior snipped ...]
Know somebody why didn't it work?

Because undefined behavior is "undefined." The C language
makes no guarantees at all about what your code will do, so it
is silly to expect an explanation of its behavior in terms of C.
The behavior may make sense in terms of a specific implementation
of C, but (1) you didn't reveal what implementation you used and
(2) even if you had, nobody would care much.

(1) $ uname -a
Linux a03-0634b 2.6.16.9 #2 Mon Jun 19 00:29:11 CEST 2006 i686 GNU/Linux

[snip]

Is any possibility to try it. In Erickson's book isn't mention about
compiler, or C implemenatation. Only about OS, gentoo.

[...]

Then whatever Erickson is trying to do is OS-specific, and not
something we can talk about here. A Linux-specific newsgroup would be
more helpful.

Incidentally, if you're trying to learn about the theory of
exploitation, either just for knowledge or to guard against it, that's
great. If your goal is to create and spread your own viruses or other
malware, I hope that nobody helps you; if you succeed in doing so, I
hope that you're caught and punished.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[tom]

Keith Thompson wrote:

tom <to******@atlas.czwrites:

>Eric Sosman wrote:

>>tom wrote:
Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
[... much undefined behavior snipped ...]
Know somebody why didn't it work?
Because undefined behavior is "undefined." The C language
makes no guarantees at all about what your code will do, so it
is silly to expect an explanation of its behavior in terms of C.
The behavior may make sense in terms of a specific implementation
of C, but (1) you didn't reveal what implementation you used and
(2) even if you had, nobody would care much.

(1) $ uname -a
Linux a03-0634b 2.6.16.9 #2 Mon Jun 19 00:29:11 CEST 2006 i686 GNU/Linux

[snip]

>Is any possibility to try it. In Erickson's book isn't mention about
compiler, or C implemenatation. Only about OS, gentoo.

[...]

Then whatever Erickson is trying to do is OS-specific, and not
something we can talk about here. A Linux-specific newsgroup would be
more helpful.

Thanks i'll try it.

>
Incidentally, if you're trying to learn about the theory of
exploitation, either just for knowledge or to guard against it, that's
great. If your goal is to create and spread your own viruses or other
malware, I hope that nobody helps you; if you succeed in doing so, I
hope that you're caught and punished.

No i'm a student, it's a school project. I am not a cracker. My goal is
show that this problems are real.

--
TP

[tom]

Mark McIntyre wrote:

On Sun, 11 Feb 2007 16:46:46 +0100, in comp.lang.c , tom
<to******@atlas.czwrote:

>Eric Sosman wrote:

>>tom wrote:
Im trying understand format string vulnerability. Source along
Erickson's HACKING: The Art of Exploitation.
[... much undefined behavior snipped ...]
Know somebody why didn't it work?
Because undefined behavior is "undefined." The C language
makes no guarantees at all about what your code will do, so it
is silly to expect an explanation of its behavior in terms of C.

>>The behavior may make sense in terms of a specific implementation
of C, but (1) you didn't reveal what implementation you used and
(2) even if you had, nobody would care much.

snip details of his implementation

>Is any possibility to try it.

Did you notice (2) above? The reason Eric mentioned this is because
CLC discusses portable standard C. Your code fragment is incorrect,
broken and nonportable.

>In Erickson's book isn't mention about
compiler, or C implemenatation. Only about OS, gentoo.

I would suggest you throw the book away, or ask the author to explain.

I'm afraid i havn't a contact to the author. My book is not original
edition, it is a Czech translation.

--
S pozdravem Tomás Pelka