– Corsaire Limited Security Advisory –

Title: Microsoft Outlook 2000 vCard Buffer Overrun (additional information)

• Revised
  Date: 01.03.01
  Application: Outlook 2000, Outlook Express
  Environment: WinNT, Win2000
  Author: Martin O'Neal [[email protected]]
  Audience: General distribution

– Scope –

The aim of this document is to clearly define some additional issues
involved in protecting against this threat.

– History –

A buffer overrun condition was discovered in the Microsoft vCard
implementation contained within certain versions of the Microsoft Outlook
application and initially announced by Joel Moses on NTBugTraq on
31.08.00 [1].

A fix was announced by Microsoft for effected versions of their products
on the 22.02.01 [2].

A proof of concept exploit for the buffer overrun flaw was announced by
@stake on the 23.02.01 [3].

– Overview –

The documents referenced in the history section above contain 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).

However, what they don't include is information on the repercussions of
this flaw when placed in the context of other flaws in the Outlook products
vCard mechanism, along with known flaws in other products. Together they
could make it possible to bypass security measures and deliver a rogue
vCard to an unsuspecting user.

It is worth restating that the Microsoft supplied fix is essential to
eliminate the threat from this particular buffer overrun flaw.

– Analysis –

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.

– Issue number 1 –

>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 [4].

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.

– Issue number 2 –

The actual vCard object format is defined within RFC2426 [4] and makes a
number of mandatory requirements that have not been implemented within the
Microsoft products. The main ones of these are:

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).

– Conclusions –

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).

– Proof of concept –

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>

– Example 1: Embedding a vCard object in an inert document type –

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.

– Example 2: Subverting analysis based on content type –

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.

– Example 3: Collusion between multiple flaws –

There is currently a documented flaw in the Baltimore MAILsweeper product
[5] 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.

– Recommendations –

Apply the Microsoft supplied fix to all effected workstations as soon as
possible.

Enable blocking of vCard objects at any entry-point gateway products that
are implemented.

Corsaire have also created a freely available plug-in that works with the
Baltimore MAILsweeper product to identify and block functional vCard
objects, no matter what form of attachment they are embedded in. This can
be obtained upon request by contacting us directly at [email protected]

– References –

[1] http://www.securityfocus.com/archive/1/79612
[2] http://www.microsoft.com/windows/ie/download/critical/q283908
/default.asp
[3] http://www.atstake.com/research/advisories/2001/a022301-1.txt
[4] http://www.faqs.org/rfcs/rfc2426.html
[5] http://www.mimesweeper.com/support/technotes/technote.asp?technote=
/support/technotes/msw4/VulnerabilityMSW42.asp

– Revision –

Altered vCard token requirements section, as incomplete in original
advisory document.

Copyright 2001 Corsaire Limited. All rights reserved.

---

CONFIDENTIALITY: This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited. If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.

DISCLAIMER: Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.

Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey GU23 7EF
Telephone:+44(0)1483-226000 Email:[email protected]

---

Delivery co-sponsored by eEye Digital Security

Protect Your Data with Retina 3.0 from eEye…Think Like A Hacker!
Traditional security measures such as firewalls and intrusion detection
systems are not enough. Retina, the Network Security Scanner, scans,
monitors, alerts, and automatically fixes network security vulnerabilities
with a touch of a button. Free 30-day trial available at
http://www.eeye.com/click.asp?referrer=ntbt&amp;P;=Retina