How did an ImageMagick vulnerability endanger Yahoo servers?

An ImageMagick vulnerability known as Yahoobleed could give hackers access to Yahoo servers. Expert Michael Cobb explains the flaw and how Yahoo handled the situation.

Yahoo has retired ImageMagick, an open source, command-line graphics file editor, due to a bleed vulnerability that persisted despite having been fixed a few months prior. What is the ImageMagick vulnerability, and how does it give attackers access to Yahoo servers?

Security researcher Chris Evans reported a bleed-type vulnerability in the image processing library ImageMagick, dubbed Yahoobleed #1, which caused the Yahoo Mail service to bleed content stored in its servers' memory.

So-called bleed vulnerabilities, like Heartbleed and Cloudbleed, leak data from a server's memory space and are a firm favorite with hackers, as they are relatively easy to exploit. Also, as they aren't contained by most sandboxing defenses, they can be exploited until vulnerable systems have been patched.

ImageMagick is over 25 years old, but has remained a popular library for displaying, converting and editing images. It is supported by PHP, Perl, Ruby, Node.js, Python and other programming languages. Over the years, ImageMagick has grown to over half a million lines of code spread over 1,000 files.

Even though the number of flaws discovered in ImageMagick in recent years has spawned a separate site that documents them, it is still integrated into various operating systems and programs, and it is used by many major sites, such as Yahoo and Facebook.

Evans found that, when he sent himself a specially crafted run length encode (RLE) image file via Yahoo Mail and viewed it in the image preview pane, it contained remnants of other users' images. The Utah Raster Toolkit RLE image format dates back to Windows 3.x, and though it is rarely used today, it is still supported by the ImageMagick library.

The ImageMagick vulnerability exists because the GetVirtualMemoryBlob() method located in ImageMagick's memory.c file doesn't guarantee zero-filled memory when allocating a suitably sized canvas for the image decode process. GetVirtualMemoryBlob() defaults to allocating memory with malloc(), which, unlike mmap() or calloc(), does not initialize or zero memory before returning a pointer. This means an uninitialized image decode buffer is allocated for the new image that may already have data in it.

Any memory content leak is serious, but what makes this ImageMagick vulnerability worse is that the Yahoo Mail process that handles thumbnails appears to be long lived, and it processes multiple images from different users. This means that, by creating an RLE image that has header flags that do not request canvas initialization, followed by an empty list of RLE protocol commands, the canvas remains uninitialized, and the final image sent to the attacker contains memory artifacts from other users' email attachments.

A real-world attack looking to scan Yahoo servers would require the hacker to repeatedly send themselves the bleed-inducing image, a process that could, no doubt, be automated. Earlier bleed vulnerabilities have typically been due to out-of-bounds reads, but as this is due to the use of uninitialized memory, it does not cause a server to crash. Better written code would launch the ImageMagick convert binary process once per thumbnail request, so any leak would only contain the attacker's own data due to process isolation.

The Yahoobleed #1 vulnerability, tracked as CVE-2017-9098, has been patched with one line of code provided by Evans. The same vulnerability was patched in GraphicsMagick, an offshoot of ImageMagick created in 2002, in March 2016. Evans made a very valid point that this lack of communication between the two projects could have left systems using ImageMagick open to attack for almost a year.

Vulnerabilities in popular software libraries are dangerous because they put so many servers, applications and users at risk. Bug bounty programs definitely help encourage responsible discovery of potential flaws, but ensuring all affected systems are protected once a patch is released remains a problem; even Yahoo servers were left unpatched and exposed for 28 months.

Rather than patch ImageMagick, Yahoo has chosen to stop using it altogether, but other web services are still likely to be vulnerable. Administrators who are concerned their systems may be vulnerable can download the 18-byte exploit included in Evan's blog post detailing the ImageMagick vulnerability.

Next Steps

Read about the differences between the Ticketbleed and Heartbleed flaws

Find out how applying a hacker mindset to your systems can help

Learn how the Docker REST API can be used against enterprises

This was last published in October 2017

Dig Deeper on Application and platform security