Re: Re: Gadu-Gadu Local/Remote Buffer Overflow vulnerability
Hi JD, 1. It was fully tested on Windows XP SP2 (lang: polish) with all patches, I'm going to test it on other systems. DEP wasn't turned on, I suppose this hack might not work with the DEP protection. This issue is exploitable on both both privileged/unprivileged user. 2. I did it because of a few reasons. Firstly, the user doesn't have to replace any file, it's enought to place it in a new directory in \Gadu-Gadu\emots\ ; Of course not everyone can do it. It is a local buffer overflow indeed, but I think that emots.txt files are supposed to be harmless by the GG users. What is more, there is a number of people downloading new sets of emoticons, and a great part of them don't check the configuration file contents. IMO a nasty exploit would spread pretty easily, after all. 3. What do you mean by asking how much bytes can you parse? Regards, j00ru//vx
Gadu-Gadu Local/Remote Buffer Overflow vulnerability
Team Vexillium Security Advisory http://vexillium.org/ Name : Gadu-Gadu Class: Buffer Overflow Threat level : VERY HIGH Discovered : 2007-11-10 Published: 2007-11-22 Credit : j00ru//vx Vulnerable : Gadu-Gadu 7.7 [Build 3669], prior versions may also be affected. ==[ Abstract ]== Gadu-Gadu is a free internet communicator used by milions of polish people. It allows to talk, hear and even see other internauts through the net. It also supports the possibility to express feelings using some provided emoticons. These emoticons' strings with associated graphic filenames are stored in emots.txt file. The GG Client is vulnerable to a buffer overflow attack, in the code that moves the emots.txt file data to some local buffers. The program doesn't check if the size of data to move is not greater than the size of the destination buffer. Successful exploitation may lead to arbitrary code execution or the process' denial of service (gg.exe termination). ==[ Details ]== Function vulnerable to the attack is placed at the 0x00443CE2 address: .text:00443CE2 HandleEmotsConfig proc near ; CODE XREF: sub_4A55F6:loc_4A5C90p .text:00443CE2 mov eax, offset loc_561ECC .text:00443CE7 call__EH_prolog .text:00443CEC mov eax, 26588 .text:00443CF1 call__alloca_probe .text:00443CF6 pushebx .text:00443CF7 lea eax, [ebp-24h] .text:00443CFA pushesi .text:00443CFB pusheax .text:00443CFC callsub_443A9E .text:00443D01 xor esi, esi (...) It is responsible for opening the \emots\_NUMBER_\emots.txt files, and then reading information about emoticons and their graphic equivalents. This is how an exemplary line of configuration file looks like: (emoticon,emoticon,...),graphic_file.gif,graphic_file.gif If there's only one string associated to a gif file, the brackets can be skipped. Also the third part of line isn't essential - it's just the name of optional graphic file in NETSCAPE GIF format. During the process of copying data from currently opened file (2nd and 3rd part of configuration line) to some local buffers, the program doesn't check the strings' lengths, what can lead to overwriting the 500-byte buffers placed on the stack. Vulnerable code that copies the name of first gfx file is shown below: .text:00443E37 loc_443E37: ; CODE XREF: HandleEmotsConfig+164j .text:00443E37 cmp al, '' .text:00443E39 jz short loc_443E48 .text:00443E3B mov [ecx], al .text:00443E3D inc ecx .text:00443E3E inc edi .text:00443E3F mov [ebp-18h], edi .text:00443E42 .text:00443E42 loc_443E42: ; CODE XREF: HandleEmotsConfig+153j .text:00443E42 mov al, [edi] .text:00443E44 cmp al, 20h .text:00443E46 jnb short loc_443E37 As you can see, there's no size limitation of the data being moved. It's, in fact, the same situation in the second piece of code: .text:00443E87 loc_443E87: ; CODE XREF: HandleEmotsConfig+1B6j .text:00443E87 cmp cl, '' .text:00443E8A jz short loc_443E9F .text:00443E8C mov [eax], cl .text:00443E8E inc eax .text:00443E8F inc edi .text:00443E90 .text:00443E90 loc_443E90: ; CODE XREF: HandleEmotsConfig+1A3j .text:00443E90 mov cl, [edi] .text:00443E92 cmp cl, ' ' .text:00443E95 mov [ebp-18h], edi .text:00443E98 jnb short loc_443E87 A Proof of Concept file created during this research exploits bugs in filename copying code, but it is also possible to execute arbitrary code using an buffer overflow in other places in the fuction - responsible for moving data such as strings describing the emoticons and so on. When copying data using code shown above, the values of some local variables, return addresses etc. may be overwritten. Modification of proper amount of stack data causes an exception. There are several reasons for the exception being generated. It can happen when the filename placed in emots.txt is longer than the size of stack, or in a function under 0x0052F5D0 address, called by the emoticon parsing code: .text:00443EEE callunknown_libname_52 ; Microsoft VisualC 2-8/net runtime to be more precise, the instruction under 0x0052F62A causes an exception, because of the fact that EDI register value is zero in that moment: .text:0052F62A rep movsd Among all the data we are able
A little advisory content correction.
There is a small mistake in the line: readme.txt /../../../../../../../../asdf.exe This filename originally looks like: readme.txt 40 spaces here /../../../../../../../../asdf.exe What I mean, is that only the readme.txt part of path is visible for the user, and the directory traversal string can be easily hidden in this way. The forty space characters aren't displayed correctly due to the fact that they are shortened to one space by the browser. j00ru
WinImage 8.10 vulnerabilities
Team Vexillium
Security Advisory
http://vexillium.org/
Name : WinImage 8.10 Multiple Vulnerabilities
Class: Denial of Service and Directory Traversal
Threat level : LOW (DoS), MED (Dir. traversal vuln)
Discovered : 2007-08-31
Published: 2007-09-15
Credit : j00ru//vx
Vulnerable : WinImage 8.10,
WinImage 8.0,
prior versions may also be affected
== Abstract ==
WinImage is an disc images' exploring application, with many
useful functions implemented, such as injecting/extracting files
from the data images, handling virtual machines' hard drives and so on.
The first vulnerability - Denial of Service - exists in the FAT image
handling function (mainly diskette image files are able to cause this kind
of application hang, but it's also possible that other image formats'
header modification may lead to such kind of program behaviour).
The succesful DoS attack is achieved by opening a special .IMG
file with its header modified. Because of bad FAT header handling,
the application may get into an infinite loop, so that the
only way is to terminate the process.
The second one - Directory Traversal vuln - was reported in .IMG
and .ISO images processing. There is no function to check whether
the filename or directory name consists a string like .. etc
during the file extraction. In this case, extracting an image file
containing folders/files with malformed names, may be used to create a file or
directory in any location (specified by attacker) on the selected partition,
without
any user knowledge.
== Details ==
1. Denial of Service vulnerability
The DoS attack is very easy to carry out, it's just about modyfying
a few bytes in the diskette disc image - IMG file. The header value, that is
not beeing checked by WinImage is BPB_BytsPerSec, WORD (2 byte size)
at offset 11, as written in Microsoft Extensible Firmware Initiative
FAT32 File System Specification.
The most important thing is clearly explained in the document:
This value may take on only the following values: 512, 1024, 2048 or 4096.
There is no such condition in program processing the FAT header. Therefore,
we can change the value to any in the range of 0-65535. After the 2-byte
modification:
EB 3C 90 29 6C 75 68 64 49 48 43 00 {00 02} 01 00
---
EB 3C 90 29 6C 75 68 64 49 48 43 00 {AA AA} 01 00
opening the changed file won't succeed, but the the application will hang
instead, getting into an infinite loop. To be more precise, the endless
loop looks like that:
.text:00415432 loc_415432: ; CODE XREF:
sub_415400+4Aj
.text:00415432 testeax, eax
.text:00415434 jbe short loc_41544C
.text:00415436 mov ecx, [esi+210h]
.text:0041543C add [ebx], ecx
.text:0041543E mov edi, eax
.text:00415440 callsub_4155C0
.text:00415445 cmp eax, 0FF0h
.text:0041544A jb short loc_415432
Having such modified file, the only thing to do is to convince somebody
to open it. This Denial of Service attack is not very harmful in fact,
although it's a typical header-based vulnerability, and is adviced to be
corrected.
Proof of Concept: http://j00ru.vexillium.org/vuln/winimage/dos_PoC.IMG
2. Directory Traversal vulnerability
An especially malformed disc image file (as before .IMG and .ISO files
processing
is vulnerable, but other formats' handling is also likely to be vulnerable) may
contain a directory/file name with an upwards dir traversal string inside,
such as:
readme.txt/../../../../../../../../sth.bat
During extraction a file named like this, WinImage should create sth.bat on
the
partition root rather then expected readme.txt in the specified path. In that
case,
it's even possible to extract a file with any name we want, to any location we
choose.
For example, exploiting this vulnerability may lead to extracton a .BAT file to
the
Autostart directory on the Windows installation partition.
Another important thing is that the real file name/path of file can be hidden
by making it look like:
readme.txt
/../../../../../../../../asdf.exe
It's same situation with folders. If one directory name is, for example,
../../../../../../../../asdf, then all the subdirectories and files
will be extracted to folder named asdf, created on the root of
partition.
Both file and directory name modifications are shown in the
PoC file provided (TEST1, TEST2 folders).
Proof of Concept: http://j00ru.vexillium.org/vuln/winimage/dir_PoC.IMG
== Solution ==
1. Denial of Service vulnerability
The best way to get rid of the ability to get WinImage hang, is adding
a function to check the BPB_BytsPerSec value, and inform user about
the image header error if it's greater than 4096 ( or even if the value
is not equal to 512, 1024, 2048 or 4096). This should
