Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert command always taking policy from global policy.xml file instead of custom path #1342

Closed
2 of 3 tasks
hctpbl opened this issue Oct 9, 2018 · 6 comments
Closed
2 of 3 tasks

Comments

@hctpbl
Copy link

hctpbl commented Oct 9, 2018

Prerequisites

  • I have written a descriptive issue title
  • I have verified that I am using the latest version of ImageMagick
  • I have searched open and closed issues to ensure it has not already been reported

Description

I use ImageMagick to convert pdf files to png, the ImageMagick version I am using (6.8.9-9) ships with a default policy.xml file that has no permissions for reading PDF files. I changed that policy.xml file and everything is working correctly, but I want to be able to have my own policy.xml file in a path of my choice that I can ship with my project, so I can deploy the project in a new server without having to configure the server's default policy.xml file every time.

According to ImageMagick v6 documentation the policy will be looked for in the following locations (I'm using the precompiled binary installation for Ubuntu 16.04):

$MAGICK_CONFIGURE_PATH
$MAGICK_HOME/etc/ImageMagick-6 
$MAGICK_HOME/share/ImageMagick-6 
$PREFIX/share/ImageMagick-6 
$XDG_CACHE_HOME/ImageMagick
$HOME/.config/ImageMagick/
<client path>/etc/ImageMagick
<current directory>

So I set the env variable MAGICK_CONFIGURE_PATH to the path I put my policy file on. I would expect the convert command to find it there and use that policy to execute, but it seems to be using the one in /etc/ImageMagick-6 anyway. The policy file is correctly found when using the command to list the policy:

$convert -list policy

Path: /home/<user>/path/to/file/policy.xml
  Policy: undefined
    rights: None 
  Policy: Coder
    rights: None 
    pattern: EPHEMERAL
  Policy: Coder
    rights: None 
    pattern: URL
  Policy: Coder
    rights: None 
    pattern: HTTPS
  Policy: Coder
    rights: None 
    pattern: MVG
  Policy: Coder
    rights: None 
    pattern: MSL
  Policy: Coder
    rights: None 
    pattern: TEXT
  Policy: Coder
    rights: None 
    pattern: SHOW
  Policy: Coder
    rights: None 
    pattern: WIN
  Policy: Coder
    rights: None 
    pattern: PLT
  Policy: Path
    rights: None 
    pattern: @*
  Policy: Coder
    rights: None 
    pattern: PS
  Policy: Coder
    rights: None 
    pattern: EPS
  Policy: Coder
    rights: Read 
    pattern: PDF
  Policy: Coder
    rights: None 
    pattern: XPS

Path: /etc/ImageMagick-6/policy.xml
  Policy: undefined
    rights: None 
  Policy: Coder
    rights: None 
    pattern: EPHEMERAL
  Policy: Coder
    rights: None 
    pattern: URL
  Policy: Coder
    rights: None 
    pattern: HTTPS
  Policy: Coder
    rights: None 
    pattern: MVG
  Policy: Coder
    rights: None 
    pattern: MSL
  Policy: Coder
    rights: None 
    pattern: TEXT
  Policy: Coder
    rights: None 
    pattern: SHOW
  Policy: Coder
    rights: None 
    pattern: WIN
  Policy: Coder
    rights: None 
    pattern: PLT
  Policy: Path
    rights: None 
    pattern: @*
  Policy: Coder
    rights: None 
    pattern: PS
  Policy: Coder
    rights: None 
    pattern: EPS
  Policy: Coder
    rights: None 
    pattern: PDF
  Policy: Coder
    rights: None 
    pattern: XPS

Path: [built-in]
  Policy: Undefined
    rights: None 

But I get a not authorized error. If I change the policy file in /etc/ImageMagick-6/policy.xml to allow reading PDF files, my convert command works.

I have also tried to place the policy file in the <current directory> from where I call the convert command, it also appears when I execute convert -list policy, but I still get the not authorized error unless I changed the global policy file.

System Configuration

  • ImageMagick version: 6.8.9-9
  • Environment (Operating system, version and so on): Ubuntu 16.04.4
@urban-warrior
Copy link
Member

If ImageMagick is installed, only the policy in the system path is enforced, otherwise it would not be much of a security policy if it could easily be overridden. In certain cases, the user can set certain resource limits but only @ a lesser value that what the administrator sets (e.g. administrator sets a memory limit of 2GB, the user can set a limit of 1GB but not 3GB).

ImageMagick has an uninstalled build option. With that build option, ImageMagick will allow the security policy to be overridden by any policy in the paths you mention in your post.

@hctpbl
Copy link
Author

hctpbl commented Oct 15, 2018

Got it. Thanks @urban-warrior.

@hctpbl hctpbl closed this as completed Oct 15, 2018
leohemsted pushed a commit to alphagov/notifications-template-preview that referenced this issue Aug 10, 2020
In https://github.com/alphagov/notifications-template-preview/pull/467
we added a new policy.xml file for ImageMagick that allow PDFs to be
read and written then tried to ensure the new file was used by setting
the `MAGICK_CONFIGURE_PATH` environment variable. The original
policy.xml file was still being picked up, so this didn't work.

It's not clear from the docs, but it seems like if ImageMagick is installed,
not built, you can't overwrite the system policy.xml and `MAGICK_CONFIGURE_PATH`
doesn't work (ImageMagick/ImageMagick#1342).
So this commit changes things to overwrite the ImageMagick policy.xml
with our own, which does work.
@klenze
Copy link

klenze commented May 6, 2022

If ImageMagick is installed, only the policy in the system path is enforced, otherwise it would not be much of a security policy if it could easily be overridden. In certain cases, the user can set certain resource limits but only @ a lesser value that what the administrator sets (e.g. administrator sets a memory limit of 2GB, the user can set a limit of 1GB but not 3GB).

I think this is fundamentally misguided. On a unixish system, the standard assumption is that a user may generally arbitrary code with that users permission. root does not configure specific permissions for bash, python or gcc or any of the myriad other programs which can be used to execute arbitrary code (including form unsafe sources, e.g. "wget http://shady-server/foo.sh -O - | bash").

If convert was installed with the setuid bit, then it would certainly have to enforce system-wide limits against the user, but last time I checked it is generally not.

From my understanding, nothing prevents the user from:

  • directly parsing pdfs directly with ghostscript
  • using LD_PRELOAD to redirect the open("etc/ImageMagick-6/policy.xml")
  • use a debugger to make the policy-checking method return the desired result or
  • just running a user-compiled version of convert,

A "security" policy which is trivial to circumvent is generally just an annoyance. This is why /usr/bin/passwd requests the old password for normal users first, but not for root (which could just write directly to /etc/shadow anyhow).

I could see the point of having e.g. "/usr/bin/convert.safe" which could be whitelisted so it is allowed to be run by a web server, but having behavior as a default for local users feels like something Mordac the preventor of information services would come up with.

A non-default -unsafe flag which prevents the uninformed user from accidentally running commands which might be harmful would be reasonable. (See rm's --no-preserve-root option.)

ImageMagick has an uninstalled build option. With that build option, ImageMagick will allow the security policy to be overridden by any policy in the paths you mention in your post.

So I should lobby my distribution to either ship that version or lock down any methods by which a user could compile ImageMagick locally, I guess :-)

@urban-warrior
Copy link
Member

The system administrator installs ImageMagick, they set the security policy per their requirements. The default security policy is to allow everything, so if there are any restrictions, the system administrator decided they were necessary per their security governance. If you want your own security policy, you can build an "uninstalled" version of ImageMagick and set your security policy to whatever you want. If users directly use delegates to bypass restrictions within ImageMagick (e.g. reading Postscript), that's okay. The policy prevents ImageMagick from contributing to possible nefarious behavior. We can't control what people do outside of ImageMagick. A good design principle is to have one way to do one thing. The security policy can prevent the uniformed user from accidentally running command which might be harmful, therefore, no special command line option or API call is required.

@dermoth
Copy link

dermoth commented Aug 27, 2022

This is a very poor security decision. If I can run commands on the system I should be able to override the system policy.

In the best case users have root access and can change the policy for everyone on the system, then other apps and users could become exploitable because the default system policy is now too lax.

This is, imho, the best scenario, as if they have root they are likely not affecting many users (probably only their own system or a single-purpose container).

If that's not scary enough, then there's the other option of compiling your own ImageMagic to bypass this. This is what would most likely happen when users are not able to change the system policy because the system is properly administered. Then most likely the user-compiled version will never get updated or checked for vulnerabilities as it "just works". This can lead to potential additional risks as new vulnerabilities are uncovered.

At the very least there should be a setting in the system policy to permit user overrides, and this should be enabled by default. To avoid changing existing behavior, an extra environment variable could be added to ignore the system policy or force the overrides when allowed by the system policy.

P.S.: ImageMagick is an awesome piece of software and even with my skills I could never even dream of writing my own tools for the simple use cases I'm using it for (at least not in a timely manner), so kudos for the developers who've made life so much easier for the rest of us. My skill are geared toward systems designs and operators workflows, and from my perspective the way policies are handled is nonsense. I wouldn't argue about the way you decode and process images without a strongly supported case showing why you're wrong, likewise I believe you should listen to the comments from specialists on the other side of the food processing chain. I've just read @klenze's comment now and it reflects very well my thoughts too. A policy than cannot be enforced isn't a policy, it's only a false sense of security.

@urban-warrior
Copy link
Member

To have a truly secure system, you must shut down all the computers, enclose the building in lead, and kill all the users. Short of that, secure systems are a compromise between security and convenience. ImageMagick is not designed to be a "secure" system-- instead its designed to function while being diligent to avoid common user errors or nefarious behaviors. We recognize that users can override any policy by simply installing their own version of ImageMagick. This is not uncommon. Safeguard, for example, secures Linux by only allowing certain approved usernames access to the Linux system. However, as the Linux user has sudo privileges, they can simply create their own user account and bypass Safeguard security. In that case, the company policy applies-- that is, once discovered you might be booted off the system. Here, the security policy extends not only to the policy set by the system administrator, but also the expected behaviors of trusted users.

Note, the user can modify the system policy-- as long as its more restrictive. For example, the system policy sets the maximum memory to 4GB. You can set it to 2GB but not 8GB.

And as we state on the ImageMagick security page, you can make ImageMagick safer by ...

  • keeping ImageMagick up-to-date. The latest releases have fixes for any security flaws we discovered in the past;
  • sanitizing any filenames or command line options you pass to ImageMagick;
  • running ImageMagick in a sanitized software container such as Docker;
  • running ImageMagick as the least-privileged user (e.g. 'nobody');
  • explicitly setting the image file type. For example, use the filename png:image.png rather than image.png. Without an explicit image type in the filename, ImageMagick guesses the image type.
  • do not create temporary files in shared directories, instead specify a private area to store only ImageMagick temporary files by setting the temporary-path security policy or the -define registry:temporary-path=/data/magick command-line option.

In the end, ImageMagick is open source. Anyone can release a version with custom behaviors such as a policy to override the system policy, as you suggest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants