Delphi and C++ Builder VCL library Heap Buffer Overflow | CoreLabs Advisories

Delphi and C++ Builder VCL library Heap Buffer Overflow

1. Advisory Information

Title: Delphi and C++ Builder VCL library Heap Buffer Overflow
Advisory ID: CORE-2014-0006
Advisory URL:
Date published: 2014-09-16
Date of last update: 2014-09-16
Vendors contacted: Embarcadero
Release mode: Coordinated release

2. Vulnerability Information

Class: Heap-based Buffer Overflow [CWE-122]
Impact: Code execution
Remotely Exploitable: No
Locally Exploitable: Yes
CVE Name: CVE-2014-0994


3. Vulnerability Description

Applications developed with Delphi and C++ Builder [1] that use the specific integrated graphic library detailed below are prone to a security vulnerability when processing malformed BMP files. The aforementioned vulnerability has been found in the VCL (Visual Component Library) allowing an attacker to use a specially crafted BMP file that produces a heap buffer overflow and potentially allows him to execute arbitrary code by performing a "client side" attack. The vendor made a partial fix of CVE-2014-0993 [5] that does not cover this heap-based buffer overflow.

4. Vulnerable Packages

  • Embarcadero® C++Builder® XE6 Version 20.0.15596.9843
  • Embarcadero® Delphi® XE6 Version 20.0.15596.9843

We also found vulnerable applications that were built with the following development tools:

  • Delphi XE5 / C++Builder XE5 (Delphi:Win32) (C++Builder:Win32)
  • Delphi XE4 / C++Builder XE4 (Delphi:Win32) (C++Builder:Win32)
  • Delphi XE3 / C++Builder XE3 (Delphi:Win32) (C++Builder:Win32)
  • Delphi XE2 / C++Builder XE2 (Delphi:Win32) (C++Builder:Win32)
  • Delphi XE / C++Builder XE (Win32)
  • Delphi 2010 / C++Builder 2010 (Win32)
  • Delphi 2009 / C++Builder 2009 (Win32)
  • Delphi 2007 / C++Builder 2007 for Win32
  • Delphi 2006 / C++Builder 2006 (Win32) and Delphi/C++Builder 2007 for Win32
  • Delphi 2005 (Win32)
  • Delphi 7 (and 7.1)
  • Delphi 6 / C++Builder 6
  • Delphi 5 / C++Builder 5
  • C++Builder 4
  • Delphi 4

Other 32b and 64b versions could be also affected.

5. Vendor Information, Solutions and Workarounds

Core Security recommends those affected use third party software such as Sentinel [3] or EMET [2] that could help to prevent the exploitation of affected systems to some extent.

Contact Embarcadero for further information.

6. Credits

This vulnerability was discovered and researched by Marcos Accossatto from the Core Exploits Writers Team. The publication of this advisory was coordinated by Joaquín Rodríguez Varela from the Core Advisories Team in close coordination with the US-CERT.


7. Technical Description / Proof of Concept Code

The library VCL.Graphics, may be used by applications developed using Embarcadero's Delphi and C++ Builder to process BMP files [4]. This library is vulnerable to a heap buffer overflow attack when a specially crafted BMP file with specific values in the BITMAPINFOHEADER.biClrUsed field are used. This allows the crafted BMP to potentially execute arbitrary code.

The ReadDIB function in the VCL library processes the BMP header in the following way: it first allocates memory to copy the header, plus 1024 bytes for the color table:

 mov eax, [ebp+HeaderSize] ; eax => 40 // Header size read from file add eax, 0Ch ; eax => eax + 12 
add eax, 400h ; eax => eax + (256 * 4) call @System@@GetMem$qqri ; // Alloc necessary memory for the 
BMP header and color table 

Later, a pointer is calculated, off 40 bytes (HeaderSize), from the first pointer; this new pointer is going to be used when working with the color table later on:

 mov eax, [ebp+BitmapInfo_] ; eax => BitmapInfo add eax, [ebp+HeaderSize] ; eax => eax + HeaderSize mov 
[ebp+ColorTablePtr], eax 

That pointer is finally used to copy from the file to the allocated region in the heap, with a user controlled size of (biClrUsed * 4):

 mov ecx, [ebx+20h] ; ecx => biClrUsed movzx edi, [ebp+OS2Format] movzx eax, byte_5F90E8[edi] ; eax => 4 // 
When edi is 0 imul ecx, eax ; ecx => biClrUsed * 4 // How much to copy to allocated memory mov edx, 
[ebp+ColorTablePtr] mov eax, [ebp+Stream] call Stream_ReadBuffer ; Stream.ReadBuffer(ColorTablePtr, 
biClrUsed * 4); 

Thus creating a heap buffer overflow and potentially allowing code execution.

7.1. Proof of Concept

Given that fixing affected applications may require recompiling them with the fixed library by the vendor, Core Security has decided not to release proof of concept code publicly at this time in order to provide affected companies with additional time for patching. Core Security is willing to collaborate with affected parties that need assistance in understanding the vulnerability.


8. Report Timeline

  • 2014-08-25: Core Security contacts Embarcadero to inform them that after reviewing the fix for CORE-2014-0004 (CVE-2014-0993), we found a way to still exploit the vulnerability. We scheduled this new advisory for September 1st, 2014.
  • 2014-08-25: US-CERT replied that they offered to forward Embarcadero the advisory.
  • 2014-08-25: Embarcadero replies that they are willing to accept the advisory forward from the US-CERT.
  • 2014-08-26: Core Security sends the US-CERT the new PoC and an analysis of the vulnerability.
  • 2014-08-28: Core Security sends the US-CERT another email asking if they received the PoC and if they were able to forward it to Embarcadero.
  • 2014-08-29: Core Security sends the US-CERT yet another email asking if they received the PoC and if they were able to forward it to Embarcadero. The advisory is going to be rescheduled for Tuesday 2st of September, considering the 1st is a US holiday.
  • 2014-08-29: US-CERT replied that they sent Embarcadero the PoC on Thursday 28th of August. The vendor asked the US-CERT if they should replace the existing fix or publish a second fix. The US-CERT doesn't expect the vendor to have a fix available for 2nd of September.
  • 2014-09-02: Core Security sends Embarcadero another email asking if they were able to develop a fix for the issue. We updated the release date for Wednesday 3rd of September in order to give the US based companies one more labor day to patch their software considering the 1st of September was a holiday.
  • 2014-09-02: Embarcadero replies that they were able to reproduce the issue and are currently investigating a fix. They request if we can delay the advisory until they have this issue fixed and tested.
  • 2014-09-02: Core Security inform them that we would appreciate to receive the fix as soon as they have it available in order to test it. We replied that we will reschedule the advisory publication for Monday 8th of September.
  • 2014-09-02: Embarcadero replies that they would like to request us to schedule the advisory publication for Monday 15th of September. They say they will provide us with the fix as soon as they have it in order to test it and confirm that the issue is resolved.
  • 2014-09-04: Core Security sends Embarcadero an email stating that we will reschedule the advisory for Monday 15th of September.
  • 2014-09-04: Embarcadero replies that they agree.
  • 2014-09-11: Embarcadero inform us that based on their review of the code the fix won't be ready on Monday, 15th of September, as we had planned.
  • 2014-09-12: Core Security sends Embarcadero an email stating that they should respect the publication date that was coordinated. We reminded them that we moved the publication date based on Embarcadero's request and scheduled it accordingly as well.
  • 2014-09-12: The US-CERT replies that as they understand the situation, they consider that the first BMP vulnerability is incompletely fixed. They suggest everyone to update their existing documentation/advisories when a complete fix is available. They also suggest that Core Security publishes the 15th of September.
  • 2014-09-12: Core Security replies the US-CERT that the advisory that we are going to publish is not an update of the existing advisory. We informed them that this is a new advisory.
  • 2014-09-12: Embarcadero informed us that they are preparing a support article for the advisory that we will publish on Monday 15th of September.
  • 2014-09-16: Core Security releases the advisory.

9. References


10. About CoreLabs

CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at:

11. About Core Security Technologies

Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations.

Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached on the Web at:

12. Disclaimer

The contents of this advisory are copyright (c) 2014 Core Security and (c) 2014 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License:

13. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team.