Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The author of this post is the creator of an autopwn bot. While on a customer engagement with a small scope that was perfectly patched, it decided to tackle a dependency that is used by millions of websites: imagemagick. After five days of searching, it had a zero-day RCE bug in the default configuration of this library. This is the story of the vulnerabilities and the disclosure process.

On the first day, it learned that extension-based filtering doesn't work because it mostly cares about magic bytes. From this, it was determined that it could process SVGs at will, and the SVG parser was reviewed. Fairly quickly, it identified a file-read vulnerability when PostScript was enabled, but exploiting it required a very generous policy. The default policy blocks PS but not EPSI, allowing for an arbitrary file read. There are two issues here: the ability to read files at all and a bad deny-list.

After another day, it learned that by shifting the magic bytes, adding a \n could be used to defeat the PostScript detection. So, using GhostScript, you could write arbitrary files to the server just by reading a file. After finding a clear RCE vulnerability via a file-write, the development team pushed back, saying that real users should have better policies in place, where the default configuration still had the issue.

After this point, they moved their client to a very restrictive set of image policies. Upon doing this, the AI bot realized that the PS module was blocked but NOT the PDF module. By using the PDF path, which is fine in production according to the maintainers, it achieves RCE again. Even after this, they found that using the magic bytes C5 D0 D3 C6 overrode the extension-based format selection, allowing for even jpgs to be processed.

The most secure policy blocked all usage of delegates. This should theoretically catch all external process invocations and reject them. Unfortunately, this protection was busted in the case of GhostScript. When GhostScript is compiled into ImageMagick as a library, it runs in-process via gsapi_init_with_args(). So, the policy check never fires.

WordPress has no ImageMagick policy to begin with, making it vulnerable in many situations. It all depends on the website and the user's capabilities. In the end, the module was silently fixed without a CVE being assigned, and the fix wasn't backported to older versions. Practically, this means that a server with defaults of the library is vulnerable to some pretty nasty things. Only the core file read and file write issues were fixed; the PDF bypass and gslib delegate execution issue were never fixed.

The maintainers' fixation on secure policies appears to be a security boundary that is different between real-world usage and maintainer expectations. As usual, if there are no good defaults, then the protection is effectively null. Overall, a great post on ImageMagick's security and the use of LLMs to find bugs.