corrupted parameters passed to variadic functions about american-fuzzy-lop HOT 18 CLOSED

Note the program runs fine if run under afl-showmap (or valgrind weirdly?).
So perhaps programs are not generally standalone with the contained 
instrumentation, and I need to adjust my make file to stop calling the just 
built programs?

Can you provide a complete test case? I don't think that va_arg is patently 
broken, because printf() and a lot of other things seem to work, so it would be 
helpful to have a test case to narrow it down.

I tried:

-- snip! --
#include <stdio.h>
#include <stdarg.h>

void foo(char* fmt, ...) {

  va_list p;
  int i, x;

  printf("fmt=%s\n", fmt);

  va_start(p, fmt);

  for (i = 0; i < 10; i++ )
    printf("%d\n", va_arg(p, int));

  va_end(p);
}

main() {

  foo("x", 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

}
-- snip! --

When compiled with -O0 and -O3 with afl-gcc, I don't see unexpected behavior 
when running standalone. In general, the instrumented programs should work OK 
outside of afl-fuzz / afl-showmap.

Very hard to reproduce. If I make one of the other uncalled functions in the 
file a bit smaller then there is no issue. So it's some weird issue with code 
text alignment or something

Are you sure it's not a subtle bug in your code? Could very conceivably 
manifest itself only with particular stack layouts, etc, so the mere act of 
injecting instrumentation could make it appear or disappear temporarily.

I'm happy to investigate, but I'm afraid I need a bit more to go on; as noted, 
this doesn't seem to repro with simple experiments.

The code is the latest http://git.sv.gnu.org/gitweb/?p=coreutils.git
It happens a few programs there that call parse_long_options().
For example uptime is failing due to invalid Version pointer passed like:

    $ src/uptime --version
    Segmentation fault (core dumped)

It was compiled like this:

    $ /usr/bin/afl-gcc -Ilib -Isrc -g -O2 -c -o src/uptime.o src/uptime.c
    afl-gcc 0.46b (Nov 14 2014 19:16:42) by <[email protected]>
    afl-as 0.46b (Nov 14 2014 19:16:42) by <[email protected]>
    [+] Instrumented 81 locations (64-bit mode, seed 0x546b9cab).
    $ /usr/bin/afl-gcc -o src/uptime src/uptime.o src/libver.a lib/libcoreutils.a
    afl-gcc 0.46b (Nov 14 2014 19:16:42) by <[email protected]>

Note just adding an unused function to uptime to change the text locations
is enough to avoid the issue :/

Attached is a failing binary in case it helps.
(with a signature signed with my key (306037D9))

Both files associated with previous comment

Aight, looking into it with coreutils from 
git://git.savannah.gnu.org/coreutils.git. Stay tuned! 

Hmm, tried with afl-0.48b on 64-bit; Linux GCC is:

gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC)

Checked out with:

git clone git://git.savannah.gnu.org/coreutils.git

Built with:

./bootstrap
CC=~/afl-0.48b/afl-gcc ./configure
make

The resulting behavior is as expected:

[lcamtuf@gopher2 coreutils]$ ./src/uname --version
uname (GNU coreutils) 8.23.64-840da
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

I'll try with gcc 4.9.2 first, just need to build it, so it may take a couple 
of hours.

s/first/next/

Wow thanks for your efforts. That's why I provided the binary since 
reproduction steps are very awkward. For completeness I was using Fedora 21 
beta and you might find it quicker to run that in a VM? 
http://fedoraproject.org/get-prerelease

BTW I temporarily disabled selinux, and ASLR with setarch -R, in case they had 
an effect, but still got the crash. Does the provided binary crash on your 
system?

One quick question: if you edit the source so that the function does not take a 
variable number of params (essentially, nuke the author parts), does it still 
have the same problem?

The fact that this happens specifically with an extern is somewhat interesting, 
too; do you get the crash when you replace it with a locally defined string?

Basically, my two best theories right now are:

1) We clobber the R8 register in the initial set up code path, unrelated to 
va_args. This would only affect functions called very early on (so parsing 
params is plausible). I need to look into this.

2) Something is wrong with your build - maybe something messed up with linking 
(because of the extern bit).

I'm actually guessing it's #1. Can you grab the latest version of afl from:

http://lcamtuf.coredump.cx/afl.tgz

...and try again? (Be sure to set CC appropriately and re-run ./configure 
before doing make clean all)

Yeah, thinking about it, it *has* to be this. You bumped into the bug for 
reasons unrelated to va_args, I think. Essentially, first call to a function in 
another .o file would have it try to call getenv() as a part of the afl setup 
code. In your libc, getenv() apparently clobbers the %r8 register, which I 
forgot to save (for some reason, I thought that %r8-%r15 are callee-saved, but 
only %r12-%r15 are).

Bingo!

I had a little fun with compiler cache when verifying:

  $ /usr/bin/afl-gcc -Ilib -Isrc -g -O2 -c -o src/uptime.o src/uptime.c
  afl-gcc 0.48b (Nov 15 2014 22:15:23) by <[email protected]>
  afl-as 0.46b (Nov 14 2014 19:16:42) by <[email protected]>

  export CCACHE_RECACHE=1
  $ /usr/bin/afl-gcc -Ilib -Isrc -g -O2 -c -o src/uptime.o src/uptime.c
  afl-gcc 0.48b (Nov 15 2014 22:15:23) by <[email protected]>
  afl-as 0.48b (Nov 15 2014 22:15:23) by <[email protected]>

The generated binaries now work as expected.

thanks!

Cool, sorry about the hiccup :-) I guess it's pretty rare for the first 
function called in an .o file to take 5+ params, and for getenv() to use 
%r8-%r11.