CVE-2022-44267 and CVE-2022-44268

[y0d4a]

Hi, can someone help me to understand which versions are affected with it?
From - to ?

thank you

[urban-warrior]

ImageMagick strongly advises setting up a security policy that is suitable for your local environment. Add this to your security policy:

<policy domain="path" rights="none" pattern="/etc/*"/>  <!-- don't read sensitive paths -->

With that policy, we get:

$ magick logo: -set profile /etc/passwd logo.png
magick: attempt to perform an operation not allowed by the security policy `/etc/passwd' @ error/blob.c/FileToBlob/1433.

You can be as draconian as you need. Use /* as the path to prevent reading any file with an absolute path. You can also protect against relative paths:

<policy domain="path" rights="none" pattern="../*"/>

See https://imagemagick.org/script/security-policy.php for a description of the ImageMagick security policy.

In the mean-time, this is an open dialog. Feel free to post use cases we might have overlooked.

[y0d4a]

thank you for workaround, but i would like to know from which version those CVS are applied.
thank you

[urban-warrior]

The ImageMagick security policy applies to all recent versions of ImageMagick and has been available since 2002 to address potential security issues. The reported CVEs may be incomplete as the authors did not mention the policy which mitigates the perceived vulnerabilities. ImageMagick is an open platform and the security policy can be adjusted to accommodate local requirements, either by limiting or expanding its default constraints.

[Lastique]

CVE-2022-44267 is a problem of "-" being embedded in a PNG file. But if I add <policy domain="path" rights="none" pattern="-"/> in policy.xml then all support for pipes is disabled. Is it possible to disable "-" interpretation in all images, including PNG, while leaving support for pipes in CLI enabled?

[urban-warrior]

ImageMagick 7.1.0-62 and ImageMagick 6.9.12-76 is no longer reactive to "-" embedded in a profile. Make sure you block sensitive paths and disable indirect reads to secure the -set profile CLI option.

[AlexLaforge]

What do you mean by "disable indirect reads" ? How to achieve that ?

[hikao]

ImageMagick 7.1.0-62 and ImageMagick 6.9.12-76 is no longer reactive to "-" embedded in a profile. Make sure you block sensitive paths and disable indirect reads to secure the -set profile CLI option

I understand this is a fix for CVE-2022-44267(Denial of service).
Is ImageMagick 6.9.12-76 version also fixed for CVE-2022-44268 (Arbinary Remote Leak)?

[urban-warrior]

As discussed, many of the vulnerability reports issued over the last 10 years are incomplete in that they don't mention that the issue can typically be mitigated by a proper security policy. No security patches or code updates are required, just modify the policy.xml security policy configuration file. ImageMagick, by default, is open. Use the security policy to add constraints to meet the requirements of your local security governance. The policy applies to both ImageMagick versions 6 & 7.

Note, the last release of ImageMagick 6 & 7 does include a patch to prevent CVE-2022-44268 without the need of a security policy. However, it is recommended to add a security policy to prevent access to your sensitive file paths. In your security policy, you can block all paths and then follow with specific paths that are allowed. Also, review other methods to keep ImageMagick secure, discussed here: https://imagemagick.org/script/security-policy.php#other.

Once you configure your policies, try these steps:

1. Doyensec provides a policy validator @ https://imagemagick-secevaluator.doyensec.com/. We have not validated it but it does provide useful information about your policies.
2. Type magick -list policy to list your security policies.
3. Add -debug policy to your CLI to trace how policies are being applied as you execute ImageMagick.

[hikao]

Thank you for providing an answer to my question. I really appreciate it.

[AlexLaforge]

What if we want to deny read & write rights from & to any folder on the disk, except certain folders ?
Would the following set of rules be acceptable, and is the order correct, or should we reverse it ?

<policy domain="path" rights="none" pattern="*" />
<policy domain="path" rights="none" pattern="C:\" />
<policy domain="path" rights="none" pattern="E:\" />
<policy domain="path" rights="read | write" pattern="C:\*\repository-folder-01\*" />
<policy domain="path" rights="read | write" pattern="E:\*\repository-folder-02\*" />

PS : We are on Windows, not Linux.

[urban-warrior]

Read https://imagemagick.org/script/security-policy.php. Note, you need to escape backslashes, e.g. c:\\\\*. To only allow certain paths, block everything and then follow with allow policies. You've done this already except for the wildcard required for the C & E drives. Now list the policies with magick -list policy and trace the polices with magick -debug policy ... to verify it is working as expected.

[AlexLaforge]

Hi @urban-warrior , thank you for your detailed and useful explanations !
I tried adding these policies, but they lead to images not being processed anymore ...

<policy domain="path" rights="none" pattern="*" />
<policy domain="path" rights="none" pattern="E:\\*" />
<policy domain="path" rights="read | write" pattern="E:\\workfolder\\*" />

[urban-warrior]

You are likely accessing a path that you have prohibited with your policy. Add -debug policy to your command-line. It should display the path that's being denied to help you debug the issue.

[AlexLaforge]

When using :

convert -debug policy logo: "E:\\workfolder\\logo.png"

The -debug policy flag returns that writing in E:\workfolder\ is not authorized... but according to my policy, it should ..sigh...

Domain: Path; rights=Write; pattern="E:\\workfolder\\logo.png" ...
convert.exe: not authorized `E:\\workfolder\\logo.png' @ error/blob.c/OpenBlob/2403.
convert.exe: WriteBlob Failed `E:\\workfolder\\logo.png' @ error/png.c/MagickPNGErrorHandler/1804.

I can't explain why this path is not authorized, based on this policy :

<policy domain="path" rights="none" pattern="*" />
<policy domain="path" rights="none" pattern="E:\\*" />
<policy domain="path" rights="read | write" pattern="E:\\workfolder\\*" />

[urban-warrior]

From the security policy web page:

Note, in file path glob patterns, use the backslash character (\) to escape characters that would otherwise be interpreted as special characters. For example: <policy domain="path" rights="none" pattern="E:\\\\*"/>

Note the 4 backslashes. Update your policy and see if that resolves the issue.

[AlexLaforge]

Unfortunately, we already tried with 4 backslashes, and the result is still the same :

Domain: Path; rights=Write; pattern="E:\\workfolder\\logo.png" ...
convert.exe: not authorized `E:\\workfolder\\logo.png' @ error/blob.c/OpenBlob/2403.
convert.exe: WriteBlob Failed `E:\\workfolder\\logo.png' @ error/png.c/MagickPNGErrorHandler/1804.

Without specifying any path restrictions, it is obviously possible to read and write from/to anywhere on the *E:* volume, including critical folders, thus motivating us to adopt a "deny-all-then-granular-allow" policy to protect against these CVE.

We are completely stuck with this simple policy, and cannot find out why it is not properly working :/

[neelgohel]

@urban-warrior @AlexLaforge @y0d4a @hikao @Lastique
Can you please specify the exact version number of ImageMagick 6 that patches the CVE-2022-44268? Thanks in advance.

[Lastique]

Please read the discussion and don't blanket-mention everyone in the thread.