Re: Imagemagick policy

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%gatalith.at@localhost> writes:

> I looked at updating ImageMagick, and the latest now delivers four
> default policy files. They are described in comments inside:

Wow, this is really hard to understand.

> ImageMagick-7.1.1-20/config/policy-limited.xml
>
>   Limited ImageMagick security policy:
>
>   The primary objective of the limited security policy is to find a
>   middle ground between convenience and security. This policy involves the
>   deactivation of potentially hazardous functionalities, like specific coders
>   such as SVG or HTTP. Furthermore, it establishes several constraints on
>   the utilization of resources like memory, storage, and processing duration,
>   all of which are adjustable. This policy proves advantageous in situations
>   where there's a need to mitigate the potential threat of handling possibly
>   malicious or demanding images, all while retaining essential capabilities
>   for prevalent image formats.
>
> ImageMagick-7.1.1-20/config/policy-open.xml
>
>   Open ImageMagick security policy:
>
>   The default policy for ImageMagick installations is the open security
>   policy. This policy is designed for usage in secure settings like those
>   protected by firewalls or within Docker containers. Within this framework,
>   ImageMagick enjoys broad access to resources and functionalities. This policy
>   provides convenient and adaptable options for image manipulation. However,
>   it's important to note that it might present security vulnerabilities in
>   less regulated conditions. Thus, organizations should thoroughly assess
>   the appropriateness of the open policy according to their particular use
>   case and security prerequisites.
>
> ImageMagick-7.1.1-20/config/policy-secure.xml
>
>   Secure ImageMagick security policy:
>
>   This stringent security policy prioritizes the implementation of
>   rigorous controls and restricted resource utilization to establish a
>   profoundly secure setting while employing ImageMagick. It deactivates
>   conceivably hazardous functionalities, including specific coders like
>   SVG or HTTP. The policy promotes the tailoring of security measures to
>   harmonize with the requirements of the local environment and the guidelines
>   of the organization. This protocol encompasses explicit particulars like
>   limitations on memory consumption, sanctioned pathways for reading and
>   writing, confines on image sequences, the utmost permissible duration of
>   workflows, allocation of disk space intended for image data, and even an
>   undisclosed passphrase for remote connections. By adopting this robust
>   policy, entities can elevate their overall security stance and alleviate
>   potential vulnerabilities.
>
> ImageMagick-7.1.1-20/config/policy-websafe.xml
>
>   Web-safe ImageMagick security policy:
>
>   This security protocol designed for web-safe usage focuses on situations
>   where ImageMagick is applied in publicly accessible contexts, like websites.
>   It deactivates the capability to read from or write to any image formats
>   other than web-safe formats like GIF, JPEG, and PNG. Additionally, this
>   policy prohibits the execution of image filters and indirect reads, thereby
>   thwarting potential security breaches. By implementing these limitations,
>   the web-safe policy fortifies the safeguarding of systems accessible to
>   the public, reducing the risk of exploiting ImageMagick's capabilities
>   for potential attacks.

> I think since ImageMagick now delivers four to choose from, admins can
> easily deploy the one the want, and we should switch back to the
> default (in this case, open) policy to match what upstream provides.

It seems obvious (hah!) that the security policy should be controlled by
something in etc as a config file, so that it survives updates.  If not,
that would be great to fix.


The Open policy description does not really make sense.  It says it is
ok to use in systems with firewalls or in Docker containers.  Because
obviously such a system will never receive or process any crafted input,
and nothing bad could ever happen.  And, "systems running pkgsrc" do not
in general meet this test.  While I normally lean to "use the defaults
that upstream recommends", I can't feel good about that in this case.

It seems semi-obvious to me that we should choose Limited as a default;
this is stated to be a middle ground, not too scary, not so far into
security-first that you can't do anything.