Lighttpd

For http auth we need to base64-decode user input; the allowed character range
includes non ASCII characters above 0x7f.

The function to decode this string takes a "const char *in"; and reads
each character into an "int ch", which is used as offset in the table.

So characters above 0x80 lead to negative indices (as char is signed on most
platforms).

Here the vulnerable code (src/http_auth.c:67)

static const short base64_reverse_table[256] = ...;
static unsigned char * base64_decode(buffer *out, const char *in) {
    ...
    int ch, ...;
    size_t i;
    ...

        ch = in[i];
        ...
        ch = base64_reverse_table[ch];
    ...
}

It doesn't matter if "broken" data is read - it just may allow more
encodings of the correct login information.

The only possible impact is a segfault, leading to DoS.

I had a look at some debian and openSUSE binaryies, and it looks like
there is always enough data (>= 256 bytes) in the .rodata section before the
base64_reverse_table table, so these binaries are not vulnerable.

Thanks to Xi Wang who discovered the issue:
---
On 11/29/2011 12:42 AM, Xi Wang wrote:

Hi,

There's a potential integer overflow in base64_decode() at http_auth.c:108 (lighttpd-1.4.x HEAD).

// const char *in;
// int ch;

1) ch = in[i];
...
2) ch = base64_reverse_table[ch];

Note that the type of in[i] is signed char. At 1) ch could be negative, and at 2) base64_reverse_table[ch] is an out-of-bounds read.

To fix it, we could change the function signature
base64_decode(buffer *out, const char *in)
to
base64_decode(buffer *out, const unsigned char *in)

- xi