Bug 22256 – net-www/mod_gzip

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Daniel Ahlberg (RETIRED) 2003-06-05 03:39:49 UTC]

Mod_gzip Debug Mode Vulnerabilities 
 
From:  
"Matthew Murphy" <[e-mail]> 
 
 
To:  
"BugTraq" <[e-mail]> 
 
 
Date:  
Sunday 22.10.13 
 
 
Multiple Vulnerabilities in mod_gzip Debugging Routines 
 
I. Synopsis 
 
Affected Systems: mod_gzip 1.3.26.1a and prior 
Risk: 
    * Development: High 
    * Production: Minimal 
Developer URL: http://www.sourceforge.net/projects/mod-gzip 
Status: Vendor is not supporting project at this time. 
 
II. Product Description 
 
"mod_gzip is an Internet Content Acceleration module for the popular Apache 
Web Server. It compresses the contents delivered to the client. There is no 
need to install any additional software on the client!" 
 
(Quote from developer page) 
 
III. Vulnerability Description 
 
The mod_gzip_printf() procedure has three vulnerabilities that are 
exploitable only when the module is compiled in its debug mode.  The 
vulnerabilities are listed in order of severity: 
 
* Stack overflow vulnerability 
 
The log line is superfluously formatted into a 2048 byte buffer before being 
passed off to Apache and/or file.  By requesting a long file name that the 
GZIP module handles, such as: 
 
GET [overflow] HTTP/1.1 
Host: www.apachesite.com 
Accept-Encoding: gzip, deflate 
 
The httpd child handling your request will segfault.  Consistent crashing 
can be seen with a buffer of about 2500 characters.  If the saved return 
address is overwritten, code execution becomes trivial. 
 
* Format string vulnerability 
 
Exploitable only when using the Apache log, this vulnerability allows for a 
remote user to submit a specially-crafted HTTP request that causes the child 
to segfault: 
 
GET /cgi-bin/printenv.pl?x=%25n%25n%25n%25n%25n HTTP/1.1 
Host: www.apachesite.com 
Accept-Encoding: gzip, deflate 
 
OR 
 
GET /cgi-bin/printenv.pl?x=%n%n%n%n%n HTTP/1.1 
Host: www.apachesite.com 
Accept-Encoding: gzip, deflate 
 
* Race condition (/tmp) 
 
mod_gzip insecurely logs debugging information when the Apache log is not 
used.  It generates a predictably-named log file and fails to check it for 
unique naming.  The log file naming is as follows: 
 
t<PID>.log 
 
An attacker who knew or guessed the PID of the httpd child servicing the 
request could overwrite arbitrary files as the superuser.  At some instances 
during mod_gzip's initialization, it logs debug events as root.  A 
well-placed series of symbolic links could cause arbitrary files to be 
overwritten.  For example, linking /tmp/t760.log to /bin/ls would overwrite 
/bin/ls if mod_gzip logged an event from a process with ID 760. 
 
A similar possibility exists on NTFS file systems on Win32 via NTFS hard 
links, but the default "Strengthen default permissions of internal system 
objects" policy prevents this. 
 
IV. Impact 
 
The impact of these issues on production sites should be minimal.  Users 
running internet-accessible sites should immediately switch from the debug 
build to the release build of the module. 
 
V. Vendor Response 
 
After communicating with Christian Kruse and Michael Schroepl, I was told 
that the developers weren't currently working on the project, and that the 
issues I had raised would be addressed with the next version.  As these 
issues have only a minor impact on most production sites, I decided to 
release this advisory to inform those still running the debug build to make 
the change to release for the security and stability of their sites.

[Comment 1 Gerardo Di Giacomo 2003-10-06 08:38:36 UTC]

--- mod_gzip_debug.c    2002-10-01 09:29:49.000000000 +0200
+++ mod_gzip_debug.patch        2003-10-06 17:36:17.000000000 +0200
@@ -94,6 +94,7 @@
 #include "httpd.h"
 #include "http_config.h"
 #include "http_log.h"
+#include <stdlib.h>
 
 #include "mod_gzip.h"
 #include "mod_gzip_debug.h"
@@ -125,7 +126,7 @@ void mod_gzip_printf( const char *fmt, .
 
  va_start( ap, fmt );
 
- l = vsprintf( log_line, fmt, ap );
+ l = vsnprintf( log_line, sizeof(log_line), "%s", fmt, ap );
 
  va_end(ap);
 
@@ -138,6 +139,10 @@ void mod_gzip_printf( const char *fmt, .
 
 void mod_gzip_printf( const char *fmt, ... )
 {
+
+ int rndNum;
+ time_t seed = time(NULL);
+
  int   l;
  char *p1;
  FILE *log;
@@ -153,10 +158,15 @@ void mod_gzip_printf( const char *fmt, .
  long pid = (long) getpid();
  #endif
 
+ srand(seed);
+
+ rndNum = 1+ (int)(1000.0*rand()/(RAND_MAX+1.0));
+ rndNum *= pid;
+
  #ifdef WIN32
- sprintf( logname, "c:\\temp\\t%ld.log",(long)pid);
+ sprintf( logname, "c:\\temp\\t%ld.log",rndNum);
  #else
- sprintf( logname, "/tmp/t%ld.log",(long)pid);
+ sprintf( logname, "/tmp/t%ld.log",rndNum);
  #endif
 
  log = fopen( logname,"a" );
@@ -168,7 +178,7 @@ void mod_gzip_printf( const char *fmt, .
 
  va_start( ap, fmt );
 
- l = vsprintf(log_line, fmt, ap);
+ l = vsnprintf(log_line, sizeof(log_line, "%s",fmt, ap);
 
  p1=log_line;
  while((*p1!=0)&&(*p1!=13)&&(*p1!=10)) p1++;

[Comment 2 Gerardo Di Giacomo 2003-10-06 09:16:06 UTC]

Created attachment 18854 [details, diff]
patch for this bug

it seems that the the patch that i pasted did not work :P
so i created an attachment

[Comment 3 Gerardo Di Giacomo 2003-10-07 07:25:34 UTC]

Created attachment 18905 [details, diff]
patch for this bug

Argh... in the previous patch I missed a ) ... this one is ok (I hope!)

[Comment 4 solar (RETIRED) 2003-10-07 08:41:41 UTC]

Gerardo, Astharot,


Nice work 
Thank you for creating a patch for this and helping us out in #gentoo-security

Hopefully woodchip will look it over and commit this patch to portage in/as
mod_gzip-1.3.26.1a-r1.ebuild in the next day or two.

[Comment 5 Donny Davies (RETIRED) 2003-10-07 12:46:13 UTC]

This bug is assigned to security@g.o and I've not done GLSA's.

If it's not handled in the next day or two I'll at least put the patch into
CVS and make a new revision.

[Comment 6 solar (RETIRED) 2003-10-07 14:57:44 UTC]

woodchip,

Well if you don't mind us touching your mod_gzip package then we can put
it in.
However it's always preferred if the maintainer fixes his/her package and
I'm assuming you might prefer that in this case. We will gladly handle the
GLSA aspect of this bug when its time.

[Comment 7 Donny Davies (RETIRED) 2003-10-07 17:59:06 UTC]

Patch is in mod_gzip-1.3.26.1a-r1.ebuild; I guess the GLSA can come next.

Thanks.

[Comment 8 Gerardo Di Giacomo 2003-10-09 10:04:48 UTC]

Created attachment 19013 [details, diff]
patch

[Comment 9 solar (RETIRED) 2003-10-11 12:58:12 UTC]

If we are not really defining the DEBUG mode when mod_gzip gets compiled
then there really is no reason to send a GLSA. 

The patch is just good housekeeping :)

[Comment 10 Andrew Cooks (RETIRED) 2004-01-18 03:54:44 UTC]

The bug was fixed on 7 Oct 2003, but -r1 is still masked. It hasn't received any attention since 11 Oct 2003. 

If I understand correctly, it's not exploitable by default on gentoo. Apache 2 is now the standard on x86 (at least)as well.

Closing as FIXED. Reopen if needed.