Prevent an integer overflow in remove_chunked_transfer_coding() that would cause...

It could be triggered by malicious web servers if Privoxy was
configured to filter the response and running on a platform
where SIZE_T_MAX isn't larger than UINT_MAX, which probably
includes most 32-bit systems.

On those platforms, all Privoxy versions before 3.0.19 appear
to be affected. Releases before 2.9.14 don't really count, though,
as they don't even try to sanity check the chunk size and thus
have bigger issues.

To be on the safe side, this bug should be presumed to allow
code execution as proving that it doesn't seems unrealistic.

diff --git a/filters.c b/filters.c
index df89372..c09bda4 100644 (file)
--- a/filters.c
+++ b/filters.c
@@ -1,4 +1,4 @@
-const char filters_rcs[] = "$Id: filters.c,v 1.159 2011/11/06 11:52:36 fabiankeil Exp $";
+const char filters_rcs[] = "$Id: filters.c,v 1.160 2011/11/12 12:56:21 fabiankeil Exp $";
 /*********************************************************************
  *
  * File        :  $Source: /cvsroot/ijbswa/current/filters.c,v $
@@ -1854,7 +1854,7 @@ static jb_err remove_chunked_transfer_coding(char *buffer, size_t *size)
          return JB_ERR_PARSE;
       }
 
-      if ((newsize += chunksize) >= *size)
+      if (chunksize >= *size - newsize)
       {
          /*
           * XXX: The message is a bit confusing. Isn't the real problem that
@@ -1867,6 +1867,7 @@ static jb_err remove_chunked_transfer_coding(char *buffer, size_t *size)
             chunksize, *size);
          return JB_ERR_PARSE;
       }
+      newsize += chunksize;
       from_p += 2;
 
       memmove(to_p, from_p, (size_t) chunksize);