COMMAND
Outlook
SYSTEMS AFFECTED
Outlook, Outlook Express
PROBLEM
Following is based on a Microsoft Security Bulletin MS01-012.
Outlook Express provides several components that are used both by
it and Outlook, if Outlook is installed on the machine. One such
component, used to process vCards, contains an unchecked buffer.
By creating a vCard and editing it to contain specially chosen
data, then sending it to another user, an attacker could cause
either of two effects to occur if the recipient opened it. In the
less serious case, the attacker could cause the mail client to
fail. If this happened, the recipient could resume normal
operation by restarting the mail client and deleting the offending
mail. In the more serious case, the attacker could cause the mail
client to run code of her choice on the user's machine. Such
code could take any desired action, limited only by the
permissions of the recipient on the machine.
Because the component that contains the flaw ships as part of OE,
which itself ships as part of IE, the patch is specified in terms
of the version of IE rather than OE or Outlook.
This bug was found originally by Ollie Whitehouse of @Stake. An
attacker could exploit this problem to run malicious code on a
target system. The user would need to open a malicious VCard
file as attachment to an email message. This is commonly done to
add a sender's address information to your local address book.
The user could also open a VCard as a file on the local or
network file system, or as a file via http
<a href="http://www.malicious-site.com/vcard.vcf">Cool file</a>
If a malicious VCard file is opened it will cause Outlook to
execute the arbitrary computer code contained within the VCard.
Any vulnerability in commonly attached file types has a great risk
as these problems are often used as the basis for mail worms.
Again this is a good example of why not to trust *ANY* attachment
from any unknown source even if the type of attachment is
considered safe.
It's worth noting that CVE#CAN-2000-0756 (a problem Joel Moses
reported to both Bugtraq and Microsoft in August 2000) is a
duplicate of this particular bug, but also includes extra details
about vCard infotypes. For more info see:
http://oliver.efri.hr/~crv/security/bugs/NT/olook19.html
Martin O'Neal added following. The above document contains
extensive technical details of the actual buffer overrun flaw,
and the way it might be exploited, which will not be repeated
here for brevity (the reader is encouraged to examine these
documents prior to continuing).
The vCard objects generated by the Microsoft products seem to
contain purely MIME encoded ASCII data, but this is not true of
cards that will be successfully accepted by the same products.
It appears that apart from the buffer overrun condition, the vCard
interface as implemented in the Microsoft products, is not
sufficiently constrained. Our analysis has highlighted two areas
that potentially give rise to practical methods of exploiting the
buffer overrun flaw.
From the evidence at hand, it seems that the entire file
containing the vCard object is read into memory in a single
operation, and is then assigned to a string object prior to
parsing. At this point in the process, it appears that there is
no bounds checking performed to ensure that the file contains
valid data. Due to this, the only character that effects the
successful parsing of a file is the presence of a NULL (which is
used to terminate a string object). This in itself merely
prevents the parsing of all information after the point that it
appears; all other characters preceding its inclusion are readily
accepted.
Once the string object is loaded, the Microsoft products then
appear to perform a simple search within the object for MIME
tokens, rather than rigorously enforcing the vCard format as
defined in RFC2426.
The result of this is that it is perfectly acceptable to include
raw data within a vCard object, and what is more, to insert a
vCard object into another document (such as within the data
section of a GIF image) as long as there are no NULL characters
preceding the vCard object itself. Note however, that this does
not mean that the vCard will magically find its way from its
hiding place to Outlook of its own volition; it will still need
some help. Why this might not be an insurmountable problem,
we'll come to in a minute.
The actual vCard object format is defined within RFC2426 and makes
a number of mandatory requirements that have not been implemented
within the Microsoft products. The main ones of these are
following one.
RFC2426 Section 2.1.1 BEGIN and END Type: The content entity MUST
begin with the BEGIN type with a value of "VCARD". The content
entity MUST end with the END type with a value of "VCARD". In
actuality neither of these type descriptors are required by the
Microsoft products, nor enforced.
RFC2426 Overview item 1. The vCard Mime Directory Profile
Registration. Profile special notes: The vCard object MUST
contain the FN, N and VERSION types. In actuality, none of these
three types are required by the Microsoft products or enforced.
This means that the only requirement for a functional vCard that
will be accepted by the effected Microsoft products is the BDAY:
token. The result of this lack of enforcement is that only the
rudimentary basics of a vCard need to be supplied; which makes
the task of embedding them a lot easier, and the task of locating
them consequently a touch harder (less token material to search
for means the increased possibility of annoying false alarms).
We now have a few interesting facts that we can turn into
real-world exploit opportunities. Firstly, we know that vCard
objects are not restricted to containing ASCII text. They can
happily contain all the possible byte values, with the lone
exception of the NULL character. This means that any
lexicographical analysis we might use to search for these
embedded vCards must be able to deal with raw binary files; not
just simple text.
Secondly, we know that we can place a vCard object in the data
space of any number of normally inert documents, such as GIF
images. This means that we can hide the vCard object from casual
inspection by products that analyse threats based on the content
type of a document (as they would not normally be looking for a
vCard within an image file).
For these examples we will use a payload that simply produces a
buffer overrun crash in the effected Outlook clients. No
exploitative code is used. The target vCard contents would be
(where the <CRLF> token represents a carriage-return line-feed
pair):
<CRLF>
BDAY:ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ<CRLF>
A standard GIF file is opened and the above string is inserted
into the data section. Any NULL characters that prefix the vCard
are replaced with '0x01' values. If the file is now opened using
any of the paint applications, it displays a valid image (possibly
with some visibly corrupt pixels). If this GIF file is now
renamed to possess a .VCF extension, then double-clicked, the
buffer overrun flaw will cause the un-patched Outlook client to
fail with an application error.
If the GIF file used in example 1 is renamed to have a .VCF
extension and then emailed through a gateway product that checks
attachment content based on their content type, the product will
correctly identify the file as being an image file.
Because of this, if any lexicographical analysis is performed to
search for vCard tokens within text, the vCard attachment might
go undetected (as an image does not typically contain text).
Additionally, if inert documents are not scanned for virus
content, any malicious payload to be inserted by the buffer
overrun might also go undetected.
There is currently a documented flaw in the Baltimore MAILsweeper
product that allows a scenario that blocks attachments by file
extension to be subverted. Taken in conjunction with the above
two flaws, this would allow an attacker to successfully embed a
malicious vCard object within an inert document type, and pass it
to an unsuspecting recipient.
SOLUTION
A patch is available to fix this vulnerability. Please read the
Security Bulletin:
http://www.microsoft.com/technet/security/bulletin/ms01-012.asp
for information on obtaining this patch.
Open File Explorer and got Tools -> Options -> File Types, scroll
down to .vcf, click advanced, and just uncheck "confirm open
after download". You open it, it won't ask you. If you have
checked it, or any of your users have, it will ask again. Running
logon scripts in a network, or sending any other "executable" file
(depending on motives) you want to send someone can enable or
disable this feature.