(Question) Inputs for validating bugs

[benjaminjellison]

After getting LAVA running, I ran it on the "toy" example you provided and I'm trying to trigger a bug. The log file has a line like this: ''' Validating bug 48 of 50 No known solution for bug with id=2274 Bug[2274](type=BUG_PTR_ADD, trigger=DUABytes[DUA[toy.c:2054, ((*ent).bar), real]][0:4](labels=[40, 41, 42, 43]), atp=ATP[11](loc=toy.c:2043, type=ATP_FUNCTION_CALL)) fuzzed = [/home/lava/lava/target_injections/toy/inputs/testsmall-fuzzed-2274.bin] Run modified program: /home/lava/lava/target_injections/toy/bugs/0/toy/lava-install/bin/toy /home/lava/lava/target_injections/toy/inputs/testsmall-fuzzed-2274.bin retval = 139 bug type is BUG_PTR_ADD RV indicates memory corruption ''' I ran the suggested command, but don't see anything different about the output when compared to the original. Is there an easy way to see the bug?

[moyix]

Hmm, are you running the program on a 32 or 64 bit system? I believe validation is done inside a 32-bit docker container.

[benjaminjellison]

I tried searching for the script that did the validation, but I was unable to see how/where it created a docker container. I assume the docker folder contains the Dockerfile, but I don't see how the validation script. I assumed it was scripts/verify.sh, but I don't see that calling any docker commands.

Unrelated, I'd suggest your documentation links to @moyix's blog posts about LAVA (i.e. starting with this post: http://moyix.blogspot.com/2016/06/how-to-add-a-million-bugs-to-a-program.html). Also, @moyix I was at NDSS and was going to say hi, but I didn't see you after the BAR workshop. Did you leave early, or did I just miss you?

[moyix]

It's slightly convoluted, but inject.sh calls run_remote and says to run inject.py on $testinghost; $testinghost comes from vars.sh, which queries your project config (the JSON file) and defaults to docker, which causes inject.py (and hence validation) do be done within Docker.

Perhaps the easiest way to see if the bug validates from within the Docker image is to use scripts/docker-shell.sh, which gives you a shell inside the Docker container we use for injection and validation. You pass it your project name.

Adding links to the blog posts is a good idea, thanks! As for NDSS, unfortunately I had to head out right after BAR – hope to catch you at another conference soon!

[benjaminjellison]

I dropped this for a while, but am picking it back up. I'm still having trouble getting it to crash on the purportedly problematic inputs. For example. I ran LAVA on file, and here's an snippet of target_injections/file/logs/inject-1.log:

Validating bug 48 of 50 
No known solution for bug with id=3183250
Bug[3183250](type=BUG_PTR_ADD, trigger=DUABytes[DUA[src/cdf-pre.c:5198, &((*d).d_storage), real]][0:4](labels=[23500, 23501, 23502, 23503]), atp=ATP[1116](loc=src/magic-pre.c:4999, type=ATP_FUNCTION_CALL))
fuzzed = [/home/lava/lava/target_injections/file/inputs/constitution_36_garfield-fuzzed-3183250.doc]
Run modified program: /home/lava/lava/target_injections/file/bugs/0/file-5.22/lava-install/bin/file -m /home/lava/lava/target_injections/file/bugs/0/file-5.22/lava-install/share/misc/magic.mgc /home/lava/lava/target_injections/file/inputs/constitution_36_garfield-fuzzed-3183250.doc
retval = 139
bug type is BUG_PTR_ADD
RV indicates memory corruption

The return value indicates a crash, but when I run that command, it runs correctly:

lava@f43c7a1f9e7f:~/lava/target_injections/file/logs$ /home/lava/lava/target_injections/file/bugs/0/file-5.22/lava-install/bin/file -m /home/lava/lava/target_injections/file/bugs/0/file-5.22/lava-install/share/misc/magic.mgc /home/lava/lava/target_injections/file/inputs/constitution_36_garfield-fuzzed-3183250.doc
/home/lava/lava/target_injections/file/inputs/constitution_36_garfield-fuzzed-3183250.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 5.0, Code page: 0

I ran this in the docker as suggested (this may be relevant, but I don't see any difference between running scripts/docker-shell.sh and scripts/docker-shell.sh file). I hope I'm not fundamentally misunderstanding what's going on here. I thought that was supposed to crash the program, but maybe that's wrong?

[AndrewFasano]

Hm, this seems unusual. File's behavior is fairly deterministic so if it crashed on an input once, it should crash on it again. Have you gotten any bugs to validate in file or other targets?

Some ideas for debugging: Look at the source for your buggy version of file- in src/cdf-pre.c:5198 is there a LAVA_LOG macro and in src/magic-pre.c:4999 is there a DFLOG macro with an argument of 1116? If so, you could try rebuilding (for best results within docker) with verbose logging with CFLAGS="-DLAVA_LOGGING -DDUA_LOGGING" make clean file install and then test the input again. Your output should have the following two lines (though other messages may be printed as well):

DFLOG:1116=XXXX: cdf-pre.c:5198
LAVALOG: 3183250: magic-pre.c:4999

The XXXX should be some number which is compared against in magic.pre.c:4999.

If going through that process doesn't help, you could try checking out the newtargets branch which has a newer version of file as a target so maybe your issue will go away with that.