Crash bash

Fuzzing Bash-4.4 patch 12 with AFL mainly fork bombed the fuzzing machine, but it also found this crash (they all have the same root cause):


It also works on a Bash 3.2.57, but some friends told me that they needed the following to reproduce:

echo -ne '<&-<${}'|bash

A Ubuntu user told me it was not reproducible at all, but I rather suspect his whoopsie didn’t want him to see it. Edit: As pointed out by Matthew in the comments it also works on Ubuntu.

It looks like a nullpointer dereference to me:

Program received signal SIGSEGV, Segmentation fault.
0x000912a8 in buffered_getchar () at input.c:565
565	  return (bufstream_getc (buffers[bash_input.location.buffered_fd]));
(gdb) bt
#0  0x000912a8 in buffered_getchar () at input.c:565
#1  0x0002f87c in yy_getc () at /usr/homes/chet/src/bash/src/parse.y:1390
#2  0x000302cc in shell_getc (remove_quoted_newline=1) at
#3  0x0002e928 in read_token (command=0) at
#4  0x00029d2c in yylex () at /usr/homes/chet/src/bash/src/parse.y:2675
#5  0x000262cc in yyparse () at
#6  0x00025efc in parse_command () at eval.c:261
#7  0x00025de8 in read_command () at eval.c:305
#8  0x00025a70 in reader_loop () at eval.c:149
#9  0x0002298c in main (argc=1, argv=0xbefff824, env=0xbefff82c) at
(gdb) p bash_input.location.buffered_fd
$1 = 0
(gdb) p buffers
$2 = (BUFFERED_STREAM **) 0x174808
(gdb) x/10x 0x174808
0x174808:	0x00000000	0x00000000	0x00000000	0x00000000
0x174818:	0x00000000	0x00000000	0x00000000	0x00000000
0x174828:	0x00000000	0x00000000

The maintainers of bash were notified.

About the CVEs in libtiff 4.0.3

There has been a lot of afl fuzzing going on, a lot of image libraries were targeted, I also fuzzed some libraries, for example libtiff. I sent around 10 to 20 crash files for the different tools to the maintainer that seemed to be kind of unique crash cases, although I didn’t analyze a lot of the crashes in-depth. Others found similar issues and CVEs like CVE-2014-8129, CVE-2014-8128, CVE-2014-8127 and CVE-2014-9330 were assigned, additionally I got CVE-2015-8870.

Here’s the example that I analyzed a little bit more closely (and that got the identifier CVE-2015-8870) in libtiff version 4.0.3 (until this month the last stable). It’s one of the errors in the bmp2tiff command line tool. Here’s what happens when you run it with one of my crash files (bmp2tiff crash-file.bmp outfile.tiff).

First, width and length variables are read from the bmp file header. Then the needed memory for the uncompressed image is calculated and allocated (line 595 in bmp2tiff.c):

uncompr_size = width * length;
uncomprbuf = (unsigned char *)_TIFFmalloc(uncompr_size);

However, there is no check for an integer overflow. So in my example afl made a file that results in the following values (gdb output):

(gdb) p width
$70 = 65536
(gdb) p length
$71 = 65544
(gdb) p uncompr_size
$72 = 524288

Where 524289 is (65536 * 65544) % MAX_INT. However, later on the width and length is used to calculate offsets on the uncomprbuf buffer, which results in pointers that are far off (heap buffer overflow).

Although I didn’t check the entire code, I think this is not easily exploitable, as it can only be used to read (more or less) arbitrary memory regions and write them to the output file. While this might be interesting in scenarios where you look for memory leaks, I doubt that it’s useful in any realistic attack scenario. Drop me a comment if I’m wrong. So the fix was to check if an integer overflow occurs on line 595 in bmp2tiff.c, which is done in the new version according to the maintainer.

Take a second and think about how many projects are probably using libtiff.

Looking into another crash file with an arbitrary WRITE and turning it into a fully weaponized exploit is still on my TODO list… we’ll see.


New year – Vallader app, fuzzing and advisories

Happy new year everybody,

As some of you know I’m learning a new language (Vallader Romansh) and because that language is only spoken by a few ten thousand people there is no dictionary Android app. So hey, here is a version I coded in half a day on github and on Google Play. I never took the time to improve it, so I thought I simply release it today (which took me another half a day). The app isn’t very stable, not well tested, but I guess better some app than no app at all. Send me pull requests 😉

Moreover, I’ve been fuzzing quiet a lot in the last few months and the results are crazy, thanks to AFL. I’m writing heap buffer overflow exploits and I hope I’ll write some more posts about it soon.

If you haven’t seen it, we’ve been releasing a few advisories in 2014.

Additionally, I just changed some settings on this page. You won’t be bothered with third party JavaScript includes on this domain anymore.

How webservers react on specific characters

One thing I did during my Master Thesis a while ago, was to test how different webservers react to all kind of characters. One of the first things I tested was all characters represented by one byte (00 to FF) and their percent encoded equivalents (%00 to %FF). Of course the results may vary with other server versions, server configurations, server side code, client libraries or the sent HTTP headers. For example python’s urllib2 is not able to send 0A (line feed) in an URI (which makes sense). I tried to use standard components as best as I could. The webservers I used were:

  • An Apache 2.2.12 server (port 80), Ubuntu 9.10 machine with PHP 5.2.10
  • On the same machine a Tomcat 6.0.26 server (port 8080) with JSP (Java Server Pages)
  • On a Microsoft-IIS/6.0, Windows 2003 Server R2/SP2 with ASP.NET 2.0.50727 a script in C# on Virtualbox 3.1.8

So here are the main results in one picture:


The ‘Name’ column means that the character was injected into the parameter name, e.g. na%00me=value&a=b. The fields with ‘S’ are explained in another section of my Master Thesis, but some of the time you can guess the behavior. E.g. I think you know what & stands for in GET parameters, right? 😉

This kind of information is useful when you are trying to write a fuzzer, that is more focused to do some tests that make sense. Would be interesting if this table is useful for someone else.