Hi, I discovered by fuzzing (using afl-fuzz) that indent 2.2.11 crashes, or at least invokes undefined behavior, on various inputs. For example, on Debian unstable:
------------------------------------------------------------
$ echo -ne '/*' |indent
Segmentation fault
------------------------------------------------------------
There are even one-character inputs that cause reads of
some_allocated_object[-1]:
------------------------------------------------------------
$ echo -ne '}' |valgrind indent
[...]
==16665== Invalid read of size 4
[...]
==16665== Address 0x51eb4ec is 4 bytes before a block of size 8 alloc'd
------------------------------------------------------------
At least some of them are rather obvious heap buffer overflows using
data from the input. Indeed, there's even a comment on these buffers
in the code in parse.c:
------------------------------------------------------------
/* Although these are supposed to grow if we reach the end,
* I can find no place in the code which does this. */
combuf = (char *) xmalloc (INITIAL_BUFFER_SIZE);
labbuf = (char *) xmalloc (INITIAL_BUFFER_SIZE);
codebuf = (char *) xmalloc (INITIAL_BUFFER_SIZE);
------------------------------------------------------------
So, I'd venture to guess that some of these are likely to be
exploitable to execute arbitrary code if untrusted input is passed to
indent (which I hope is unlikely anyway).
Here's a bunch of test files which, when passed via standard input to
indent, all cause slightly different crashes or out-of-bounds accesses
(verified by compiling indent with clang -fsanitize=address;
alternatively, you could run indent under valgrind):
http://sliedes.kapsi.fi/indent-crashes.tar.gz
Or individually:
http://sliedes.kapsi.fi/indent-crashes/
Sami
signature.asc
Description: Digital signature
_______________________________________________ bug-indent mailing list bug-indent@gnu.org https://lists.gnu.org/mailman/listinfo/bug-indent
