AOH :: HP Unsorted W :: TB12530.HTM

WinImage 8.10 vulnerabilities
WinImage 8.10 vulnerabilities
WinImage 8.10 vulnerabilities

Team Vexillium
Security Advisory 

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+4A=19j
.text:00415432                 test    eax, 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                 call    sub_4155C0
.text:00415445                 cmp     eax, 0FFFFFF0h
.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: 

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:


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 
Both file and directory name modifications are shown in the 
PoC file provided (TEST1, TEST2 folders).

Proof of Concept: 

== 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 be enough to eliminate
this kind of DoS vulnerability.

2. Directory Traversal vulnerability

In the case of this vuln, the only thing to do is to check all the files' and
directories' names. If there are any ".." strings found, they should be simply
removed from the name before the extraction process itself. It is also a nice idea  
not to run the WinImage program with administrative privileges, just to disable
the access of the most important windows directories like "Program Files", "WINDOWS" etc ;>

== Vendor status =
Vendor has been informed about these vulnerabilities, but not yet released 
fixed program version. 

== Disclaimer =
This document and all the information it contains is provided "as is",
without any warranty. Author is not responsible for the misuse 
of the information provided in this advisory. The advisory is
provided for educational purposes only.

Permission is hereby granted to redistribute this advisory, providing
that no changes are made and that the copyright notices and
disclaimers remain intact.

Copyright (C) 2007 j00ru of the Vexillium.

The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH
We do not send spam. If you have received spam bearing an email address, please forward it with full headers to