300 points: Why should PGP Signature in an email cause Outlook97 to crash?

Ref to Question "MAPISP32 - invalid page faiult in MINET32.DLL" (sic) - any help greatly appreciated!
Searching on MINET32.dll finds it.
Who is Participating?
vvksanConnect With a Mentor Commented:
Sure - sorry I didnt look at this earlier.

Here is the problem

Opening an ASCII armored file can cause the creation of an arbitrary file on the target machine. On the Windows platform this can lead to the execution of arbitrary code on the target machine.

The PGP ASCII Armor parser provided with most versions of PGP
(see 'Vulnerable Versions' section below) contains a behaviour that
allows the creation of an arbitrary file in the same directory as the
armored file. Since this file can contain arbitrary bytes, this can
easily lead to the execution of arbitrary code on the Windows platform.


ASCII Armored files include PGP keys, detached signature files and PGP
encrypted files.

It is possible to wrap a specially formed ASCII Armored file around a file
with arbitrary name and contents. When the armored file is parsed by PGP,
the binary file will be 'extracted'.

Because of a potentially dangerous behaviour inherent in the way that the
Windows operating systems load DLLs, if the 'extracted' file is a DLL, a
number of applications can be 'fooled' into loading the rogue DLL and
therefore executing malicious code.

It should be stressed that this DLL loading behaviour is not due to any
error in PGP, but is rather a behaviour inherent in the Windows operating
systems, affecting almost every major windows application.

Before explaining in further detail exactly how this can be achieved, the
role of ASCII armored files should be more fully explained.

PGP ASCII Armor Files:

Using PGP it is possible to digitally 'sign' a document with a private
key that only the person signing the document has access to. This process
produces a signature file (.sig) with a name corresponding to the document

This 'signature' can subsequently be verified by anyone who has

1) The signed version of the document
2) The signature (.sig) file, and
3) The public key corresponding to the private key that was used to
create the 'sig file.

The strength of the mechanism lies in the fact that public keys can be
freely disclosed without disturbing the security of the process; the
private key is used to sign a document and the public key to verify the
signature. It is currently computationally infeasible to derive the
private key from the public key, so this signature/verification process
provides a digital mechanism by which it can be demonstrated with a
reasonable degree of certainty that a given individual signed a document.

Both public keys and detached signature files can be stored in a format
known as 'ASCII armored'. This is a text based format that is generally
easy for editors on most operating systems to handle. A file encrypted in
PGP can also be stored in ASCII armored form, to better facilitate
transmission through email gateways.

When an ASCII armored file is parsed in the versions of PGP under
discussion, the ASCII armor parser processes the contents of the file. A
behaviour of this parsing code causes an armored file constructed in a
deliberate, malicious manner to create an arbitrary file, normally in the
current working directory of the process. This can be a number of
different directories depending upon how the user has invoked the parser,
but is likely to be one of

1) The 'system' temp directory (c:\temp, /tmp or other directory depending
on OS)

2) The directory containing the armored file

3) The working directory of an email client

The created file can have an arbitrary name and arbitrary contents. It
could, for example, contain a Trojan horse program, a perl script, a
forged version of a document or a program designed to attack the
integrity of PGP itself.

It should be borne in mind, however, that on UNIX platforms this file is
created with the 'execute' bit turned off; this greatly mitigates the risk
associated with this issue.

It should also be noted that immediately after the file is created,
most versions of PGP will alert the user with an error such as, "Found no
PGP information in these file(s)". This is a simple means by which the
behaviour can be detected.

The behaviour occurs because the ASCII armor parser (implemented in the
file "pgpPrsAsc.c") will extract a binary file that it encounters in a
normally ASCII - armored file type.

We illustrate the seriousness of the issue using the example of the
current commercial distribution of PGP, 7.0.3, maintained by PGP Security
Inc., running on the Windows platform.

Windows DLL Loading Mechanism:

Due to the manner in which the Windows operating systems load DLLs
(Dynamic link libraries) a malicious dll file created using the bug
described above to can be loaded the next time the user performs either of
the following actions:

1) Opens an application, such as a Microsoft Office application, Adobe
Acrobat or WinZip by opening a file in the directory containing the
malicious .dll

2) Verifies a pgp .sig file in the same directory as the .dll

This behaviour can be achieved by creating a .dll with the appropriate
entry point functions and naming it 'clbcatq.dll' or 'ntshrui.dll' (in
the first case)  or pgpsc.dll (in the second).

The applications load the malicious .dll because they require a .dll file
of the specified name and the .dll in question is not in the 'KnownDLLs'
registry key. Windows therefore searches the current working directory of
the process for a dll with the desired name; since the malicious .dll has
the correct name Windows loads it and the 'entry point' function in the
malicious dll is called.

When an application is started by clicking on a file type that it
'handles' in Windows Explorer, the current working directory of that
application is set to the directory containing the file.

An example .sig file is provided that, when 'verified', will create a
file called 'pgpsc.dll'. When loaded, this dll will pop up a message box
containing the text "The signature is valid". When the message box is
acknowledged, the .dll will terminate the process that loaded it. This
.sig file can be renamed '.asc' (the standard extension of exported PGP
public keys), and will elicit the same behaviour.

Thus, after the first time the example signature file is verified,
the message box will be popped up whenever any signature file is verified
in the directory containing the dll. This message box could of course be
made to look exactly like the message box popped up by PGP when a
signature is correctly verified.

I assume the reason your program is crashing is the underlying bug that causes this problem.
cmccannaAuthor Commented:
Thanks wksan, need to discuss it further, have added comments here:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.