-- Corsaire Limited Security Advisory -- Title: Microsoft Outlook 2000 vCard Buffer Overrun (additional information) Date: 01.03.01 Revised: 1.03.01 Application: Outlook 2000, Outlook Express Environment: WinNT, Win2000 Author: Martin O’Neal [martin.oneal@corsaire.com] Audience: General distribution Reference: c010301-001 -- 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 affected 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 affected 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 affected Outlook clients. No exploitative code is used. The target vCard contents would be (where the token represents a carriage-return line-feed pair): BDAY:ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -- 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 affected 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 info@corsaire.com -- CVE -- The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2001-0145 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. -- 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 -- a. Altered vCard token requirements section, as incomplete in original advisory document. b. Included CVE reference. -- Distribution -- This security advisory may be freely distributed, provided that it remains unaltered and in its original form. -- Disclaimer -- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Corsaire accepts no responsibility for any damage caused by the use or misuse of this information. Copyright 2001 Corsaire Limited. All rights reserved.