Early this morning, word came out about a critical bug in ImageMagick, which was quickly nicknamed ImageTragick. Transloadit is a sponsor and long time user of ImageMagick, so it is no surprise that people are worried that Transloadit might be impacted by this bug. Frankly, we were worried as well.

As of yet, we have not been able to exploit our service with this bug, even though the exploit code has not yet been released. The investigation is still ongoing, but we can state with some degree of certainty that we should not be impacted. Even before this bug in ImageMagick came to light, we already had a system in place to verify whether a file advertised as being an image is, in fact, really an image. We use a piece of software called ExifTool for this purpose and it should offer sufficient protection against any exploits using this bug.

We have since double-checked with its author Phil Harvey and he reassured us that

ExifTool parses the start of the file to determine the file type. For most types this is just a magic number test as you mentioned, but for some types without a magic number some processing is required. Exiftool uses the extension only as a clue to the particular variety of file when there are multiple file types with the same format (e.g. ASF/WMV/WMA/DIVX or DOC/PPT/XLA).

If the file is not recognized, then no MIMEType is returned and ExifTool gives an "Unknown file type" error.

So, for now, apart from the advertised workarounds, this tool will adequately protect Transloadit and you will be safe in continuing to use our service.

But, what if in a month or two more serious vulnerabilities are uncovered in ImageMagick? Or in ExifTool, for that matter.

It certainly raises a concern. Any tool will, of course, have its fair share of bugs and many bugs can be exploited. These bugs are usually quickly addressed and users are supposed to upgrade as soon as possible. But then again.. Transloadit cannot always upgrade instantly, since we need to maintain backwards compatibility for our users. Ideally, we want to keep all software up to date, while gracefully deprecating older versions and supporting them for a longer time, so customers have a chance to verify and adjust to new versions, as opposed to doing sudden overnight upgrades.

It is clear we need to limit what our tools can do (wrong), to buy us time in case the next vulnerability hits us harder.

Since the very beginning, we have ran our tools under a non-privileged system user, which does not have access to secret keys. Exploiters would, however, still be on the host system. This means that if there were to be a zero day root exploit, we would be in trouble. So if we could add more layers of security, that would be even better.

This is why, in parallel to assessing this vulnerability and trying to come up with an exploit, different team members have started working on containerizing our encoding tools. This way, our tools don't have access to anything on the host system, besides the media files they need to work on. This would even allow us to run vulnerable tools in production without giving exploiters the opportunity to snoop on others, or cause serious harm in other ways.

This will, of course, take some time to complete and we will be gradually rolling out support for it.

Regrettably, 100% security is a myth, but we hope you will feel assured that we are keeping Transloadit as safe as we can. If you have any more questions or concerns with regard to this issue, don't hesitate to reach out.

Update 2016-07-01: We have found that to run our encoding tools containerized in a secure way, we'll want to wait until we can run one-off jobs without requiring sudo privileges. This is in the works. In the meantime, we have finalized and deployed a big update so that our encoding machines (that would be most susceptible to these kind of attacks) now run without any secrets. They can take jobs out of a queue via read-only, and export them via append-only. All other secrets and privileges have been stripped.

Update 2016-08-02: We've been working with security researcher Florian Courtial to add additional filtering of bad SVG images that we were still susceptible to in some cases (although since the encoding machines had been dumbed down, no real harm could have been done).