Jul 26 2017

Google Releases Security Updates for Chrome

Original release date: July 26, 2017

Google has released Chrome version 60.0.3112.78 for Windows, Mac, and Linux. This version addresses multiple vulnerabilities that, if exploited, may allow an attacker to take control of an affected system.

Users and administrators are encouraged to review the Chrome Releases page and apply the necessary updates.



This product is provided subject to this Notification and this Privacy & Use policy.

Jul 26 2017

Analyzing CVE-2017-0190: WMF Flaws Can Lead to Data Theft, Code Execution

CVE-2017-0190 is a recently patched vulnerability related to Windows metafiles (WMFs), a portable image format mainly used by 16-bit Windows applications. Recently we have seen an increase in the number of vulnerabilities related to WMFs and EMFs (enhanced metafiles) in the GDI32 library.

Most often, these vulnerabilities lead to sensitive information disclosure from the process heap. They can also open the door to arbitrary code execution if the attacker uses them in combination with other vulnerabilities. Because WMFs are used in popular applications such as Microsoft Office, Paint, and Internet Explorer, the vulnerability has a huge attack surface.

CVE-2017-0190 describes a vulnerability in a maliciously crafted WMF that contains a record calling the function SetDIBitsToDevice() with malformed parameters from the GDI32 library, and can lead to information disclosure.


A WMF stores a list of function calls that are issued to the Windows Graphics Device Interface (GDI) layer to display an image on screen.

Figure 1: Format of Window metafile.

The format consists of a header and an array of metafile records, which store the function ID and the parameters required for it. The GDI32 PlayMetaFileRecord function parses each record and invokes the function corresponding to the function ID in the metafile record.

The minimum size for a metafile is 18 bytes. A file of this size contains the header and no records. The format of the file header:

Figure 2: Format of a metafile header.

Each record is of variable size, depending on the function call and number of parameters passed. The format of each record:

Figure 3: Format of a metafile record.

The final record in a WMF should be an end-of-file record. This comprises three words, and its function ID is zero.

The vulnerability

A malformed WMF is parsed by PlayMetafileRecord(), which calls the SetDIBitsToDevice() function based on the function ID field of the record. SetDIBitsToDevice() belongs to the GDI32 library and calling it with improper parameters can cause an out-of-bounds-read vulnerability.

SetDIBitsToDevice()paints a device independent bitmap (DIB) onto a device. This involves copying color data from a DIB to the memory device context (MDC). An out-of-bounds read happens when memcpy is used to copy DIB data to the MDC of the malformed metafile.

The record that calls SetDIBitsToDevice():

Figure 4: A malformed WMF record.

When the malformed WMF executes, the parameters are converted to arguments for SetDIBitsToDevice():

Figure 5: Parameters for the function SetDIBitsToDevice().

A DIB contains color and dimension information. A DIB structure consists of a bitmap header followed by the color data. Windows supports two types of bitmap headers, bitmapinfoheader and bitmapcoreheader; the DIB structure is called bitmapinfo or bitmapcoreinfo.

In Figure 5, lpvBits points to the color data and lpbmi points to the bitmap header. The structure of the bitmapinfoheader and bitmapcoreheader:

Figure 6: Bitmap header structures.

The minimum value for the bcSize field of bitmapcoreheader is 0xc and that of bitmapinfoheader is 0x28 (header size).

For CVE-2017-0190, the value of the bcSize field in the DIB record for a malformed WMF is 0xc, as shown in Figure 4, which confirms that the structure is a bitmapcoreheader.

Figure 7: BitmapCoreInfo from the record.

The function PlayMetafileRecord() calculates the size of the DIB data in the metafile record. This is 0xC for the malformed record. The size calculated by PlayMetafileRecord() is passed as a parameter to the CheckAndGetBitmapBits() function, which compares it with 0x28. If the value is less than 0x28, CheckAndGetBitmapBits() parses it as the bitmapcoreinfo structure. However, there is no color data following the header. So the source for copying the data in SetDIBitsToDevice() contains null.

The destination is an MDC structure. The PvNewRecord() function creates the MDC buffer. The size of the buffer is calculated from the length field of the cScanLines(0xffff) field of the record, shown in Figure 5. It then calls memcpy to copy color data from the source to the destination.

The length parameter for memcpy is calculated from the cScanLines parameter passed to SetDIBitsToDevice, which is 0xffff. This results in an out-of-bounds read.

Figure 8: Crash in memcpy.

Windows patch

Microsoft fixed CVE-2017-0190 in the May patch.

Figure 9: Comparing the code with patch diff.

As we explained, in the unpatched version CheckAndGetBitmapBits()compares the size of the DIB calculated by PlayMetafileRecord() with 0x28. If the value is less than 0x28, it parses the DIB as bitmapcoreinfo structure.

But in the patched version, if the value is less than 0x28, CheckAndGetBitmapBits() clears the return value, that is, sets it to zero and exits. Thus, PlayMetafileRecord() moves to the next record, leaving behind the malformed record.


Our analysis of the patch shows that Windows no longer uses the bitmapcoreheader structure for a DIB in a metafile record, thereby preventing many vulnerabilities associated with it.

A WMF can be used with many applications that use the gdi32 library. This increases the risk because the attack surface is large. All Windows users should keep their systems patched with the latest updates.

McAfee blocks this attack with signature ID: 0x45206000.


The post Analyzing CVE-2017-0190: WMF Flaws Can Lead to Data Theft, Code Execution appeared first on McAfee Blogs.

Jul 25 2017

Joomla! Releases Security Update

Original release date: July 25, 2017

Joomla! has released version 3.7.4 of its Content Management System (CMS) software to address several vulnerabilities. A remote attacker could exploit some of these vulnerabilities to take control of an affected website.

US-CERT encourages users and administrators to review the Joomla! Security Release and US-CERT's Alert on Content Management Systems Security and Associated Risks and apply the necessary update.

This product is provided subject to this Notification and this Privacy & Use policy.

Jul 25 2017

NoMoreRansom – One year on!

One year on.  It is fair to say that the No More Ransom project not only exceeded our expectations, but simply blew these initial expectations out of the water.  A collaboration between six partners (McAfee, EC3, Dutch Police, Kaspersky Lab, AWS and Barracuda) has now grown to include more than 100 partners across the public and private sector.  We often hear people talk about Public-Private Partnerships, but here is a true example of that commitment in action.

Because of this commitment from all the partners, this initiative has resulted in the successful decryption of more than 28,000 computers.  Let us put that into context, for zero cost, victims of ransomware who do not have to be customers of any security provider can get their data back for nothing.  They don’t have to fill in a survey, enter their email address, provide their credit card details, in fact they don’t even have to worry about obfuscating their IP address.  For the first time, there is another option.  No longer are victims faced with the option of a) lose my data or b) pay criminals.

So thank you to all of our partners, thank you to those of you that tweeted, blogged about it.  This site has been successful, in fact so successful that we even have ransomware named after us.

Of course, the Queen of England gets a boat named after her, we get ransomware!  Well that’s okay, because it shows that as the tens of millions of dollars we have prevented going into the hands of criminals, they have taken notice.

We will not stop, in fact, we need more partners, more decryption tools, and more successes.   The message of #DontPay seems to be working (as we witnessed with WannaCry and nPetya), and we will continue in our efforts to hurt the bottom line of criminals.


The post NoMoreRansom – One year on! appeared first on McAfee Blogs.