Home / exploits Drupal Imagecache security vulnarability DDOS attack *youtube
Posted on 01 October 2013
Nearly a year ago, long before I decided to move out of Drupalwork entirely, I reported a security vulnarability in Drupal 7 core in imagecache. Since imagecache is used on most Drupal6 instances this problem occurs there too. I had the draft for this poste, tucked away on an offline disk (security-details should not live "online" or in "the cloud", ever); and, obviously, the day I arrive in Thailand for a vacation, Drupal released the CVE. I made a proof of concept, and a tool to test it. The issue itself is really simple, the solution is hard; because Imagecache was designed "wrong" in the first place. Let me explain. You have really basic Drupal7-site on http://example.com, with content-type story that has an image-field. Using three imagecache-styles: "medium", "large" and "thumbnail". Imagecache works by creating new images from an original, on demand, when a particular url is requested: <img src="http://example.com/sites/default/files/styles/medium/public/field/image/news.jpg" /> Dissecting that url, we see: http://example.com/sites/default/files/ is where uploaded files are stored. This can also be something like http://acme.com/sites/acme-is-evil.org/files/ in case of multisite. /styles/ is the directory where imageges are cahed under. /medium/ is the style applied to this image /public/ the "driver", usually either "private" or "public". /field/image/news.jpg where the image is stored. The original can therefore be found at http://example.com/sites/default/files/field/image/news.jpg In this case, a derivative called medium is created. Because creating images is heavy, they are stored on disk, so a next time, the webserver can serve this image right-away. Let me repeat that: Because creating images is heavy, they are stored on disk. The idea is as simple as it is wrong: The first time (when the image is created) a full Drupal is booted up, that Drupal-instance applies the various image-manipulations you have configured for that style, and then serves and saves the image. "But why is that Wrong?", you ask? Because you never know when the heavy stuff will be invoked. It is unpredictable. And because the heavy stuff is initialized by your visitors. People from the evil, outside world. They can fire up your image-creating just by visiting urls. DDOS This is a typical DDOS vector: making a server do heavy stuff by throwing something at it from outside. Typically in an orchestrated attack that involves many people from many places throwing stuff at it. The actual issues: mixing images and styles Everything above is not a large problem, because 90%, or more, of the images used in img-tags on your site, are already created and cached on disk. An attacker will need to find the last 10% and request these urls. This is limited. But, there are more, far more, possible images then those you use in the img-tags. We have two images. A frontpage-banner and a user-avatar. They are usually used with two imagecache styles: http://example.com/sites/default/files/styles/avatar-thumb/public/users/123.jpg http://example.com/sites/default/files/styles/front-banner/public/field/image/fancy_banner.png I could just swap the styles and create a front-banner from the user-avatar, and an avatar from the banner, like so: http://example.com/sites/default/files/styles/front-banner/public/users/user_123.jpg http://example.com/sites/default/files/styles/avatar-thumb/public/field/image/fancy_banner.png And what is worse, you can pull any image in your files directory through imagecache. Including that huge 7MB hi-res upload you forgot there. And if you consider the fact the tool imagemagick (often used as engine to convert the images) can actually handle pdfs, html and many other files you probaly have lying around in your files directory, you know how much your system can be hurt. This all gets worse with the size of the images that can be abused and the heavyness of the imagecache-styles you have defined. Adding watermarks, smartcropping, overlays, rounded corners and whatnot make the generation of a derivative much heavier then
