afl-cmin chokes on spaces in file names

[Jonathan Neuschäfer]

Hi,

when I run afl-cmin on a directory with file names that contain spaces, it gets
a little confused:

> $ mkdir input; echo hello > "input/a b"
> $ afl-cmin -Q -m none -i input -o min cat
> corpus minimization tool for afl-fuzz by <lca...@google.com>
>
> [*] Testing the target binary...
> [+] OK, 171 tuples recorded.
> [*] Obtaining traces for input files in 'input'...
> Processing file 1/1... /usr/bin/afl-cmin: line 305: input/a: No such file or directory
> Processing file 2/1... /usr/bin/afl-cmin: line 305: input/b: No such file or directory
>
> [*] Sorting trace sets (this may take a while)...
> cat: min/.traces/a: No such file or directory
> cat: b: No such file or directory
> [+] Found 0 unique tuples across 1 files.
> [*] Finding best candidates for each tuple...
> Processing file 1/1... sed: can't read min/.traces/a: No such file or directory
> Processing file 2/1... sed: can't read min/.traces/b: No such file or directory
>
> [*] Sorting candidate list (be patient)...
> [-] Error: no traces obtained from test cases, check syntax!


Replacing every

for fn in `ls "$IN_DIR"`; do

with

ls "$IN_DIR" | while read fn; do

makes afl-cmin behave correctly, but might be a little non-idiomatic (maybe).

Setting $IFS to '\n' breaks some other code in afl-cmin.


Cheers,
Jonathan

[Jakub Wilk]

* Jonathan Neuschäfer <j.neus...@gmx.net>, 2015-05-23, 23:24:

>when I run afl-cmin on a directory with file names that contain spaces,
>it gets a little confused:
>

[...]

>
>Replacing every
>
> for fn in `ls "$IN_DIR"`; do
>
>with
>
> ls "$IN_DIR" | while read fn; do

In general, this should be simpler and more robust:

for fn in "$IN_DIR"/*; do

Unfortunately, not all instances of `ls ...` in afl-cmin's can be
replaced by wildcards that easily.

Recommended reading:
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

--
Jakub Wilk

[Michal Zalewski]

> Unfortunately, not all instances of `ls ...` in afl-cmin's can be replaced
> by wildcards that easily.

Yup, the uses are very intentional and difficult to lose. It's
unlikely that we can make this tolerant of arbitrarily bad filenames,
but spaces should be easy to accommodate. I just wasn't expecting
people to do that, but it's more a testament to my dir naming habits
than anything else.

/mz

[Michal Zalewski]

Actually, even replacing for `ls...` with ls | while read -r fname is
probably not an option, because it puts us in a subshell, which will
change quite a few things. An intermediate file would do, I suppose.

/mz

[Ketil Froyn]

There are ways to avoid the subshell:

http://stackoverflow.com/questions/2376031/reading-multiple-lines-in-bash-without-spawning-a-new-subshell

Ketil

--
You received this message because you are subscribed to the Google Groups "afl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michal Zalewski]

> http://stackoverflow.com/questions/2376031/reading-multiple-lines-in-bash-without-spawning-a-new-subshell

Nice, didn't know about the <[space]<(foo) syntax.

[Jonathan Neuschäfer]

I don't typically use spaces in filenames either, but I was importing a
bunch of test cases created by someone else.


Jonathan

[Jakub Wilk]

* Michal Zalewski <lca...@gmail.com>, 2015-05-23, 17:15:

>>http://stackoverflow.com/questions/2376031/reading-multiple-lines-in-bash-without-spawning-a-new-subshell
>Nice, didn't know about the <[space]<(foo) syntax.

For those confused about the syntax: "<" is normal stdin redirection,
and "<(foo)" is (Bash-specific) process substitution.

You can achieve the same with more familiar here-documents and command
substitution:

while read fn; do
...
done <<EOF
$(ls "$IN_DIR")
EOF


Oh, and if you decide to use "read", you should almost certainly call it
with the -r option.

--
Jakub Wilk

[David A. Wheeler]

On May 23, 2015 5:43:29 PM EDT, Jakub Wilk <jw...@jwilk.net> wrote:

>Recommended reading:
>http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

Thank you! In this case, the following URL might be especially useful:
http://www.dwheeler.com/essays/filenames-in-shell.html


--- David A.Wheeler