Possible arbitrary file leak

[Hassan El Jacifi]

More details can be found here:

https://www.metabaseq.com/imagemagick-zero-days/

Affected versions:

    Injection via "-authenticate"
    - ImageMagick 6: 6.9.8-1 up to 6.9.11-40
    Explotation via MSL:
    -ImageMagick 6: 6.9.11-35 up to 6.9.11-40

[David Zuelke (dzuelke)]

This affects 20.04 and 22.04. It's fixed in 18.04 already, as https://ubuntu.com/security/CVE-2022-44268 mentions.

[David Zuelke (dzuelke)]

Any news here? Marc Deslauriers committed a fix for bionic on Feb 9 (https://launchpad.net/ubuntu/bionic/+source/imagemagick/+changelog), but focal and jammy are still vulnerable.

Debian have classified this as severity "grave": https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030767

I agree with this. It's trivially exploited using a crafted PNG. Every Ruby on Rails app, for example, shells out to `convert` out of the box for image resizing. It's a very standard use case.

Debian have also fixed it in bullseye (= same version as on jammy), only buster (= same version as on focal) remains unpatched.

[David Zuelke (dzuelke)]

The fix committed to bionic applies cleanly to focal:

ubuntu-imagemagick % git checkout origin/applied/ubuntu/focal-security
Previous HEAD position was 9d9d88c18 8:6.9.7.4+dfsg-16ubuntu6.15 (patches applied)
HEAD is now at d5cfbaeb8 8:6.9.10.23+dfsg-2.1ubuntu11.4 (patches applied)

ubuntu-imagemagick % git cherry-pick ff63fb0005ef2b9a35ca0811fcf391824586d0dc
Auto-merging coders/png.c
[detached HEAD 0d1b05180] [PATCH] possible DoS @ stdin (OCE-2022-70); possible arbitrary file
 Author: Marc Deslauriers <email address hidden>
 Date: Thu Feb 9 12:11:42 2023 -0500
 1 file changed, 13 insertions(+), 2 deletions(-)

For jammy, the upstream commit (https://github.com/ImageMagick/ImageMagick6/commit/d77c01e560e973177feed4915ffd7dd1a45fd763) applies almost verbatim; the preprocessor conditionals from upstream ("#if 0 /* security risk -- disable for now */") around the removed block in magick/property.c are not in jammy, so that gets rejected:

ubuntu-imagemagick % git checkout origin/applied/ubuntu/jammy
Previous HEAD position was d5cfbaeb8 8:6.9.10.23+dfsg-2.1ubuntu11.4 (patches applied)
HEAD is now at bc5d3ac18 8:6.9.11.60+dfsg-1.3build2 (patches applied)

ubuntu-imagemagick % curl -s https://github.com/ImageMagick/ImageMagick6/commit/d77c01e560e973177feed4915ffd7dd1a45fd763.patch | patch -p1
patching file 'magick/property.c'
Reversed (or previously applied) patch detected! Assume -R? [y] n
Apply anyway? [n] y
1 out of 1 hunks failed--saving rejects to 'magick/property.c.rej'
patching file 'wand/mogrify.c'

[David Zuelke (dzuelke)]

Jammy needs a few more commits from upstream for a clean apply:

ubuntu-imagemagick % git checkout origin/applied/ubuntu/jammy
Previous HEAD position was d5cfbaeb8 8:6.9.10.23+dfsg-2.1ubuntu11.4 (patches applied)
HEAD is now at bc5d3ac18 8:6.9.11.60+dfsg-1.3build2 (patches applied)

ubuntu-imagemagick % curl -s https://github.com/ImageMagick/ImageMagick6/commit/be3b2a02cbb9c9affa7b0afa0665ed4b4bb0f47b.patch https://github.com/ImageMagick/ImageMagick6/commit/222845f6a0848c1e1c567bb1618617e786523bb2.patch https://github.com/ImageMagick/ImageMagick6/commit/87d719c194cc9356cdcf5df578bbea25582a290c.patch https://github.com/ImageMagick/ImageMagick6/commit/d77c01e560e973177feed4915ffd7dd1a45fd763.patch | patch
patching file 'magick/property.c'
patching file 'magick/property.c'
patching file 'magick/property.c'
patching file 'magick/property.c'
patching file 'wand/mogrify.c'

This then also includes https://github.com/ImageMagick/ImageMagick6/commit/be3b2a02cbb9c9affa7b0afa0665ed4b4bb0f47b which appears to fix another vulnerability.

At this point I am not sure if the fix applied to bionic (https://git.launchpad.net/ubuntu/+source/imagemagick/commit/?id=7b0f88e3da8a0aca0774318be77c6e476c537334) is even complete. The commit message sort of points to https://github.com/ImageMagick/ImageMagick6/commit/3c5188b41902a909e163492fb0c19e49efefcefe, and I believe https://github.com/ImageMagick/ImageMagick6/commit/23bf43133d5fc525afafdc47398cd92b3b68797d is related as well.

It appears like https://git.launchpad.net/ubuntu/+source/imagemagick/commit/?id=7b0f88e3da8a0aca0774318be77c6e476c537334 is the original upstream fix, and that was later improved, or fully fixed, using the patches I linked?

[David Zuelke (dzuelke)]

So I think this was originally (for OCE-2022-77) fixed with these commits:

https://github.com/ImageMagick/ImageMagick6/commit/be3b2a02cbb9c9affa7b0afa0665ed4b4bb0f47b
https://github.com/ImageMagick/ImageMagick6/commit/3c5188b41902a909e163492fb0c19e49efefcefe

And then, probably more fully, with these commits, of which I've seen d77...763 referenced in various places that discuss CVE-2022-44267 and CVE-2022-44268:
https://github.com/ImageMagick/ImageMagick6/commit/222845f6a0848c1e1c567bb1618617e786523bb2
https://github.com/ImageMagick/ImageMagick6/commit/87d719c194cc9356cdcf5df578bbea25582a290c
https://github.com/ImageMagick/ImageMagick6/commit/23bf43133d5fc525afafdc47398cd92b3b68797d
https://github.com/ImageMagick/ImageMagick6/commit/d77c01e560e973177feed4915ffd7dd1a45fd763
https://github.com/ImageMagick/ImageMagick6/commit/48b46bc91301b7206bfd4126a459984bd6abe3d4

Could also just be a refactor, but e.g. Debian seems to have applied both fix chunks.

[Seth Arnold (seth-arnold)]

On Mon, Feb 27, 2023 at 12:52:15PM -0000, David Zuelke wrote:
> I agree with this. It's trivially exploited using a crafted PNG. Every
> Ruby on Rails app, for example, shells out to `convert` out of the box
> for image resizing. It's a very standard use case.

Unfortunately this is not a new situation for ImageMagick:
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
"Total number of vulnerabilities : 630"

If you've built your applications to accept untrusted inputs from users
and then hand it to ImageMagick for processing, I strongly recommend that
you take steps to secure your environment:

- confine the application with an AppArmor profile
- confine the application with a seccomp profile
- run it as a user with very limited write permissions
- configure rlimits or cgroups on the service to prevent it from consuming
  excessive resources
- configure the networking stack to limit what network resources can be
  reached

ImageMagick is incredibly powerful software but it's also got a long
history of not being suitable for untrusted inputs.

I expect we'll address these CVEs sooner or later but it's important
that everyone who builds applications with ImageMagick understand the
risks and take appropriate actions to mitigate against exploits. This
is true of all software but especially important for ImageMagick.

Thanks

[David Zuelke (dzuelke)]

You're of course correct in principle, but the trouble here is that this is a vulnerability that's very hard to counter using OS limits/profiles or ImageMagick profiles, because you need to write user input to some location on the file system in order to process it, and so at least that file system location is automatically vulnerable to exfiltration, because the ImageMagick process must be allowed to read it to load the uploaded image.

On top of that, I for instance work for a platform provider where we can't even know ahead of time what filesystem location a customer's code (or the library/framework they're using) will use for e.g. uploaded file storage - is it /tmp, is it somewhere else - so it's not feasible to lock down paths using an ImageMagick policy in a way that doesn't break countless existing customers.

[Launchpad Janitor (janitor)]

This bug was fixed in the package imagemagick - 8:6.9.11.60+dfsg-1.3ubuntu0.22.10.2

---------------
imagemagick (8:6.9.11.60+dfsg-1.3ubuntu0.22.10.2) kinetic-security; urgency=medium

  * SECURITY UPDATE: Denial of Service
    - debian/patches/CVE-2022-44267.patch: possible DoS @ stdin (OCE-
      2022-70); possible arbitrary file leak (OCE-2022-72) (LP: #2004580)
    - CVE-2022-44267
  * SECURITY UPDATE: Information Disclosure
    - debian/patches/CVE-2022-44268.patch: move -set profile handler to CLI
    - CVE-2022-44268

 -- Paulo Flabiano Smorigo <email address hidden> Fri, 24 Feb 2023 11:21:38 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package imagemagick - 8:6.9.11.60+dfsg-1.3ubuntu0.22.04.1

---------------
imagemagick (8:6.9.11.60+dfsg-1.3ubuntu0.22.04.1) jammy-security; urgency=medium

  * SECURITY UPDATE: Denial of Service
    - debian/patches/CVE-2022-44267.patch: possible DoS @ stdin (OCE-
      2022-70); possible arbitrary file leak (OCE-2022-72) (LP: #2004580)
    - CVE-2022-44267
  * SECURITY UPDATE: Information Disclosure
    - debian/patches/CVE-2022-44268.patch: move -set profile handler to CLI
    - CVE-2022-44268

 -- Paulo Flabiano Smorigo <email address hidden> Fri, 24 Feb 2023 11:40:25 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package imagemagick - 8:6.9.10.23+dfsg-2.1ubuntu11.5

---------------
imagemagick (8:6.9.10.23+dfsg-2.1ubuntu11.5) focal-security; urgency=medium

  * SECURITY UPDATE: Information Disclosure
    - debian/patches/CVE-2022-44268.patch: move -set profile handler to CLI
      (LP: #2004580)
    - CVE-2022-44268

 -- Paulo Flabiano Smorigo <email address hidden> Fri, 24 Feb 2023 11:47:55 -0300

[Paulo Flabiano Smorigo (pfsmorigo)]

Hello David Zuelke (dzuelke), I saw your updates in the LP only today after I published the new release. I think I backported all required fixes for both CVE-2022-44267 and CVE-2022-44268. Can you check if everything was fixed correctly? I'm ok to add new fixes if necessary.

[David Zuelke (dzuelke)]

Hi Paulo Flabiano Smorigo (pfsmorigo),

alright so, I looked at it for jammy, focal and bionic.

First, jammy (I guess kinetic too?) has missing commits. The contents of CVE-44267.patch should be undone by CVE-44268.patch; this line remains in the source but has been removed upstream in the improved/refactored fix for the vulnerability:

+ (LocaleCompare(key,"profile") == 0) ||

And at least one code formatting commit (e.g. the last one in the list below) is also not there, might be useful for the future, as it would allow patches for the same piece of code to apply more cleanly, should there be the need for another backport.

If you take the jammy sources and apply all the existing patches except the last two CVE-2022-*, you can then simply apply all the commits from upstream in sequence:

(original fix)
https://github.com/ImageMagick/ImageMagick6/commit/be3b2a02cbb9c9affa7b0afa0665ed4b4bb0f47b
https://github.com/ImageMagick/ImageMagick6/commit/3c5188b41902a909e163492fb0c19e49efefcefe
(improved or refactored fix)
https://github.com/ImageMagick/ImageMagick6/commit/222845f6a0848c1e1c567bb1618617e786523bb2
https://github.com/ImageMagick/ImageMagick6/commit/87d719c194cc9356cdcf5df578bbea25582a290c
https://github.com/ImageMagick/ImageMagick6/commit/23bf43133d5fc525afafdc47398cd92b3b68797d
https://github.com/ImageMagick/ImageMagick6/commit/d77c01e560e973177feed4915ffd7dd1a45fd763
https://github.com/ImageMagick/ImageMagick6/commit/48b46bc91301b7206bfd4126a459984bd6abe3d4

They apply cleanly:

curl -s https://github.com/ImageMagick/ImageMagick6/commit/be3b2a02cbb9c9affa7b0afa0665ed4b4bb0f47b.patch https://github.com/ImageMagick/ImageMagick6/commit/3c5188b41902a909e163492fb0c19e49efefcefe.patch https://github.com/ImageMagick/ImageMagick6/commit/222845f6a0848c1e1c567bb1618617e786523bb2.patch https://github.com/ImageMagick/ImageMagick6/commit/87d719c194cc9356cdcf5df578bbea25582a290c.patch https://github.com/ImageMagick/ImageMagick6/commit/23bf43133d5fc525afafdc47398cd92b3b68797d.patch https://github.com/ImageMagick/ImageMagick6/commit/d77c01e560e973177feed4915ffd7dd1a45fd763.patch https://github.com/ImageMagick/ImageMagick6/commit/48b46bc91301b7206bfd4126a459984bd6abe3d4.patch | patch

I'd either put them into two patch files (first two commits in one, the rest in the others), or all into one. Right now, CVE-44267.patch contains just one of the two commits necessary for the original mitigation, so applying only that results in half-fixed and possibly broken code until CVE-44268.patch is also applied.

Second, focal, there is now an anomaly in the code that makes it behave differently. The bionic and jammy versions, when fed an exploiting PNG, will just ignore the exploit.

Focal however, while no longer vulnerable in that it exfiltrates the file to the headers, now returns the "profile" field with the value that the attacker fed in:

# convert exfiltrate-etc-hosts.png -resize 100x100 PNG:- | identify -verbose PNG:-
…
    png:text: 3 tEXt/zTXt/iTXt chunks were found
    png:tIME: 2023-02-28T22:00:26Z
    png:tRNS: chunk was found
    profile: /etc/hosts
    signature: e7e2dcff542de95352682dc186432e98f0188084896773f1973276b0577d5305...

[Paulo Flabiano Smorigo (pfsmorigo)]

For jammy and kinetic, I renamed the patch files as a sequence and added an additional mitigation from Debian. There is no patch missing from your list, I did a diff after applying all changes and the result is the same of your command. No missing patch left.

For focal I also rename the patch, changed as you suggested, and add the additional mitigation too.

The new packages are available at:
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=imagemagick

Can you check if it's ok? About the POC, please send to my email that it's included in the changelog, please? I'll add it to the integrated tests we do for the package.

[Greg Whiteley (greg-whiteley)]

On focal the patch for this (or the repackaging thereof) in 8:6.9.10.23+dfsg-2.1ubuntu11.6 seems to cause gsfonts not to be found - logged as #2012684

[David Zuelke (dzuelke)]

Okay, this needs immediate reverting, Paulo - CVE-2022-44267_44268-2.patch (or -3.patch for jammy) removes any access to /etc/, so ImageMagick can't even load it's own /etc/ImageMagick/type-ghostscript.xml for GS font usage anymore!

See bug https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/2012684

This "mitigation" should not have been added. My PoC PNG file exfiltrated /etc/hosts, but it could just as well have been /var/log/syslog, or /usr/local/foobar/etc/secretfile, or /proc/1/environ. There is no point in trying to address this via a policy file. The fix must be in code, and it is, so this policy file change can be removed again.

I am attaching corrected and cleaned up patches for focal and jammy, split into two parts the way I initially proposed.

(Your focal patch files are named ..._1.patch and ...-2.patch, FYI).

[David Zuelke (dzuelke)]

(You can of course also combine the two patch files into one; up to you)

[Paulo Flabiano Smorigo (pfsmorigo)]

Thanks for the heads up!

So I removed the additional mitigation for all affected releases and compare your patches with the ones in the package.

For focal, there were no changes, just indentations and line breaks as you can see here:
https://pastebin.ubuntu.com/p/NQZWgRbbfy/

For jammy and kinetic, there were two lines that I modified to be exactly as yours.

The new releases are building in proposed and will be published after some testing:
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=imagem&field.status_filter=published&field.series_filter=

[David Zuelke (dzuelke)]

Cool, thanks.

Yeah I ported the newline and indentation changes as well, to potentially allow future patches to apply more cleanly, but it's a detail (you also have some tab-based indentation mixed with spaces).

Thanks for addressing this quickly!