Server: Don't use Imagick in server, and don't recommend it

Created on 16 Dec 2018  路  36Comments  路  Source: nextcloud/server

A few days ago it was brought up to my attention that using Imagick could have very negative effects on security. The Nextcloud snap decided to not using it due to that fact, and I've now mitigated the same threat(s) as well by not using it in the Nextcloud VM.

Here are the discussion regarding the decision in the Nextcloud snap, and I think it totally makes sense not to use it in the Nextcloud Server as well.

The situation now though is that it's recomended and the setup checks will inform the user that the package is missing. As Nextcloud is advertising it's secure, then why use a package that is prune to a lot of CVEs in the past?

Regarding alternatives I think this post sums it up quite well.

Please consider removing the recommendation in future versions, and please also consider replacing the use of Imagick with something better and more secure.

0. Needs triage enhancement security technical debt

Most helpful comment

Well, or the fact that you wouldn't want to bloat your PHP with loading "everything" as a module straight into PHP. And all that ImageMagick is capable of (various formats, ...) is a huge pile of functionality. Why would you want to load that for each and every request, even when executing a small job on the CLI or something, where usually you wouldn't need that module? If it can be abstracted by some library to either use the pecl-functionality or exec the external binary or provide some fallback that would imho be fine. For various other systems there is IM or GM as a binary (for a CMS like TYPO3 for example) but not loaded as a module into PHP.
(A similar case is having a huge functionality like PHP separate and hot loaded as a mod_php into your webserver.)

All 36 comments

Ref https://github.com/nextcloud/server/pull/12821

I see the concerns and could imagine to move the warning into the theming app that some feature are not working because imagick is not present.

@skjnldsv @juliushaertl looks like @nextcloud/vm and @nextcloud/snap not going to add imagick. @nextcloud/docker added imagick a few days ago.

Edit: There is already a warning that some things does not work: https://github.com/nextcloud/server/blob/3068f07ad98ab6ec0aa96027aa2ef45240e809a6/apps/theming/templates/settings-admin.php#L136

Please consider removing the recommendation in future versions, and please also consider replacing the use of Imagick with something better and more secure.

Nothing allow us to properly convert images types (especially svg) with php other than imagick (that I'm aware of) unfortunately.

Apart from this favicon svg generation the theming app works fine without imagick?

@danielkesselberg avatars will be not as great looking without imagick.
Previews too :)

How about the performance without imagick?
This does also affect the gallery app: https://github.com/nextcloud/gallery#supporting-more-media-types

From what I've read, most of the ImageMagick CVEs come from individual filters or filetypes that we probably don't care about -- is there a way to whitelist policy.xml so that we only allow the few formats that we want to support? In addition, checking that the magic header of files is actually correct (for the formats we want to support) would protect against most malicious files.

ImageMagick (and GraphicsMagick to a lesser extent) have had quite a large number of CVEs, mostly due to the sheer amount of formats and features that users need to process images. I would say a good first step would be to figure out a whitelist hardening configuration that we can use across the board, and then we can evaluate switching away from ImageMagick if that's not sufficient.

There are also a couple of ways we could restrict ImageMagick through seccomp or by putting it inside an empty network namespace (and a mount namespace which has everything mounted-over except /lib64 and the file that is being accessed -- though this will require a bit of work since it requires having some sort of unveil feature).

@skjnldsv So something like https://github.com/flyimg/flyimg wouldn't work?

@enoch85 that would require shell_exec. Yes, we could rely on external software (like inkscape for example). But this is not really recommended to do on php. @rullzer ?

EDIT: sorry, I thought it was another software. Yes, we can use an external docker as well. We actually have a PoC somewhere for that. But this is a really heavy dependency and this would not scale to every setup. Also, most people don't use docker :/

Thanks for this, @enoch85. It's probably no surprise that I completely agree on this issue. In the snap it's not even _possible_ for people to use it, so folks will just see the warning forever and be unable to do anything. So at the very least, packagers should be able to disable this warning without triggering an integrity failure. Even better, Nextcloud should just stop suggesting it be installed if it's not. If one doesn't miss the functionality it provides, all it does is make the general populous less secure. Best yet: find an alternative so everyone can enjoy the functionality without trading security for it.

Best yet: find an alternative so everyone can enjoy the functionality without trading security for it.

Let's be clear here, we all agree :stuck_out_tongue_closed_eyes:
Having another php lib that could do the job would be ideal, but I don't have anything else to suggest unfortunately. I'm open to suggestion though :)

I'm glad we agree on that, but I'm also realistic: I don't know of an alternative off the top of my head either. While we look for one, can Nextcloud please stop complaining if imagick is not installed?

How about a temporary solution that shows this special warning as one that can be confirmed as read and then be permanently hidden?

Is it just SVG that GD didn't support? How about https://github.com/meyfa/php-svg?

I'm not sure if a less common extensions with only few/one maintainers more secure (and more reliable for e.g. compatibility) than ImageMagick.

There are indeed more filetypes, but:

Technically Nextcloud can also generate the previews of other file types such as PDF, SVG or various office documents. Due to security concerns those providers have been disabled by default and are considered unsupported. While those providers are still available, we discourage enabling them, and they are not documented.

https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/previews_configuration.html
https://github.com/nextcloud/gallery#supporting-more-media-types

@enoch85

So something like https://github.com/flyimg/flyimg wouldn't work?

It seems like that's more like an API/microservice to manipulate images, but under the hood it's also using ImageMagick https://github.com/flyimg/flyimg#technology-stack:

Image manipulation: ImageMagick

I'm glad we agree on that, but I'm also realistic: I don't know of an alternative off the top of my head either. While we look for one, can Nextcloud please stop complaining if imagick is not installed?

It is not a hard error message, but a warning, so I see no reason why, we should hide this. It just informs admins that they are missing a dependency that might cause some features to not work properly. Regarding the security concerns, if previews for those files are not enabled we don't pass user provided files to imagemagick as far as I know. The theming app is limited to admins, so there is no attack vector here, since the admin is considered as trusted anyway.

As soon as imagick is available it can be used by any application, no? That's the big problem here. It's easy to use incorrectly and it's easy to install third-party apps that do so.

How about GraphicsMagick, a fork of IM. Does it have the same security problems?

http://www.graphicsmagick.org/

From their website:
Here are some reasons to prefer GraphicsMagick over ImageMagick:

GM is more efficient so it gets the job done faster using fewer resources.
GM is much smaller and lighter (3-5X smaller installation footprint).
GM is used to process billions of files at the world's largest photo sites (e.g. Flickr and Etsy).
GM does not conflict with other installed software.
GM suffers from fewer security issues and exploits.

GraphicsMagick seems to be API compatible to imagemagick, so it could be a drop in replacement in any setup as far as I can tell.

https://pecl.php.net/package/gmagick there is no stable release :disappointed:

The imagemagick/GraphicsMagick binary is only required for extended file types like SVG:
https://github.com/nextcloud/docker/issues/594#issuecomment-459859737
Is php-imagick also that worse?

php-imagick is just a php wrapper for the binary Imagemagick.

I am getting better results in terms of speed with Imagick.

This might contribute to the conversation

https://ownyourbits.com/2019/06/29/understanding-and-improving-nextcloud-previews/

I wonder how we can assess how much of a risk Imagick is and how much we can mitigate, since it does perform better according to my testing, which is quite important for low end devices.

While we look for one, can Nextcloud please stop complaining if imagick is not installed?

Would be very nice for NC 17. Just saying. :)

Stumbled across this: https://docs.nextcloud.com/server/stable/Nextcloud_Server_Administration_Manual.pdf (4.10.3)

EDIT: It actually says in the Nextcloud manual that you should "Disable preview image generation".

Often standard-webspaces have IM or GM, but not as a php-module. So imho having Nextcloud support IM and/or GM externally would be great if it's "really needed". And if it's available externally don't complain about a missing PHP-module. I don't think "loading everything into PHP" is a good solution.
Maybe NC can use a wrapper-library?

EDIT: It actually says in the Nextcloud manual that you should "Disable preview image generation".

currently with NC 18b (18.0.0.4), setting in config.php

'enable_previews'         => 'false',

does NOT quiet/eliminate the warning in 'overview'; this still exists:

This instance is missing some recommended PHP modules. For improved performance and better compatibility it is highly recommended to install them.
    imagick

Last I checked that warning came from the theming app.

@kyrofa
saw your comment on other thread

The warning will go away if you disable the theming app. 

If that's the preferred remediation , cool. Can theming app be disabled in config.php? in sample config,

/**
 * If you are applying a theme to Nextcloud, enter the name of the theme here.
 * The default location for themes is ``nextcloud/themes/``.
 *
 * Defaults to the theming app which is shipped since Nextcloud 9
 */
'theme' => '',

but not clear how to correctly/safely DISABLE the app ...

need to look in the right place!

sudo -u wwwrun php occ app:list | grep them
  - theming: 1.9.0
sudo -u wwwrun php occ app:disable theming
    theming disabled

does the trick.

no more warning about imagick in overview

Can a decision on this be done? Wouldn't ImageMagick/GraphicsMagick as a separate binary be equally well suited for performance and compatibility? I think it's a good alternative instead of having all compiled into PHP itself.

Isn't the whole problem that ImageMagick has had some security issues, where by submitting false/crafted image files, some arbitrary code could be executed on the server?

In my opinion the risk assessment must be different for public, corporate or home/private users. I do not mind using IM since I only have NC for family and friends. But if I were hosting IM on a shared hosting, the situation might be different.

An alternative to IM might be to use GraphicsMagick, assuming there is a similar PHP module like PECL-Imagick, or to implement image processing in pure PHP. I think that kind of task would be very difficult.

Well, or the fact that you wouldn't want to bloat your PHP with loading "everything" as a module straight into PHP. And all that ImageMagick is capable of (various formats, ...) is a huge pile of functionality. Why would you want to load that for each and every request, even when executing a small job on the CLI or something, where usually you wouldn't need that module? If it can be abstracted by some library to either use the pecl-functionality or exec the external binary or provide some fallback that would imho be fine. For various other systems there is IM or GM as a binary (for a CMS like TYPO3 for example) but not loaded as a module into PHP.
(A similar case is having a huge functionality like PHP separate and hot loaded as a mod_php into your webserver.)

@neufeind Everything you said. :+1:

Was this page helpful?
0 / 5 - 0 ratings