Mod_gzip Debug Mode Vulnerabilities From: "Matthew Murphy" <mattmurphy@kc.rr.com> To: "BugTraq" <bugtraq@securityfocus.com> 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.
--- 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++;
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
Created attachment 18905 [details, diff] patch for this bug Argh... in the previous patch I missed a ) ... this one is ok (I hope!)
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.
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.
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.
Patch is in mod_gzip-1.3.26.1a-r1.ebuild; I guess the GLSA can come next. Thanks.
Created attachment 19013 [details, diff] patch
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 :)
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.
