bugtraq - Vulnerabilities in Portable Executable (PE) File Format For Win32 Architecture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <NHBBILBHFGGDKDNJKCHGAEOKCDAA.exurity@rogers.com>
Date: Wed, 9 Apr 2003 09:51:36 -0400
From: "Exurity Inc." <exurity@...ers.com>
To: <bugtraq@...urityfocus.com>
Subject: Vulnerabilities in Portable Executable (PE) File Format For Win32 Architecture

Hi, Everyone on this list:

Please find http://members.rogers.com/exurity/pdf/PE.pdf a research paper on
the vulnerabilities of PE File Format For Win32 Architecture (especially
x86). These vulnerabilities are probably well known. Some might have been
used or exploited by many. The main concept of this research article is
about the fact that the free virtual space between sections is the hiding
place for embedded code and a launching pad for bigger mobile code, let's
not forget to mention, and security risks. Actually, for more sophisticated
embedded code, it is possible in theory to shift code around within an
executable to embed even without the free virtual space reported in this
paper.

In summary, this paper addresses a few vulnerabilities in Win32 architecture
(x86 in particular) as follows:

* The explicit linking of Dynamic Link Library executables into a process,
especially the GetProcAddress and LoadLibrary API functions, has far more
consequences than it facilitates normal program developers the flexibility
in linking to their libraries dynamically. These two API functions make the
exploit code, embedded code, and other highly mobile code possible.
* The intact PE header information, including import and export library
info, left in RAM for a process provides the strong "vines" to be followed
up for GetProcAddress and Kernel32ModuleBase from many climbing points.
* The virtual address gap between two sequential sections of one executable,
either .exe or .dll, is wide enough to harbor a few "mice that carry
elephants with them through the gap".
* Lack of checking, or weak checking mechanism, for the integrity of
executables on the operating system (and/or anti-virus programs) during the
preparation for launching executables enables the modification of executable
files and execution of new mobile code relatively easy. It seems a lot of
components fail to detect the modification of executables at all.
* Executables, once compiled, linked and delivered, are prone to be modified
by other programs and most of them do not have run-time self-protection
mechanism implemented. This weakness is not only limited to Win32
application programs. Many executable files for other operating systems fail
to check on themselves during the run-time as well. But the dynamic linking
functionalities provided on Win32 make the embedding of mobile code
especially dangerous.

Microsoft and CERT were submitted with this report before. Since these
vulnerabilities are quite fundamental, it probably will take a while to get
things fixed.
However, these vulnerabilities are probably not that new and are not
first-layer vulnerabilities as buffer overflow ones. Therefore, we release
this report as background research paper and warn the public about the
security risks. For your convenience, the EmbedMe.c source file is attached
as well.

Peter Huang

Download attachment "EmbedMe.c" of type "application/octet-stream" (5522 bytes)