CVE-2021-22204

This bug was fixed in the package libimage-exiftool-perl - 12.16+dfsg-2

---------------
libimage-exiftool-perl (12.16+dfsg-2) unstable; urgency=medium

  * Add patch CVE-2021-22204.patch, taken from upstream release 12.24.
    The patch fixes CVE-2021-22204: Improper neutralization of user data in
    the DjVu file format in ExifTool versions 7.44 and up allows arbitrary
    code execution when parsing the malicious image.
    Thanks to William Bowling for the bug report on Launchpad.
    (Closes: #987505) (LP: #1925985)

 -- gregor herrmann <email address hidden> Sat, 24 Apr 2021 22:40:21 +0200

The status of this bug says "Fix Released". How can one install this released fix on Ubuntu 20.04.2 LTS (Focal Fossa)?

The publicly available proof of concept arbitrary code execution on hackerone [1] works as-is on the latest exiftool (11.88-1) in the focal repositories. This makes it a security risk to run exiftool.

[1] https://hackerone.com/reports/1154542

Launchpad is tracking the status against the current development release of Ubuntu (21.10) only - as can be see on the Ubuntu CVE tracker, https://ubuntu.com/security/CVE-2021-22204 this is not resolved for other Ubuntu releases yet.

Also since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

Thank you Alex for your explanation. Below my conclusions after digging around to learn more about how exiftool ends up in Ubuntu.

It seems that Ubuntu is using the debian version of libimage-exiftool-perl as-is. Therefore it was probably easy to get the fix released for Ubuntu 21.10 because it uses the same version of libimage-exiftool-perl as debian testing and unstable (12.16); that is, the debian patch could be used as-is.

However, backporting the patch specifically for Ubuntu 20.04 (LTS) seems to be required, because Ubuntu 20.04 uses 11.88 and debian stable uses 11.16. Debian patched their 11.16, so maybe it is easy to apply that patch to 11.88 as well.

I'm not really sure where that patch would need to go though. The debian team would have no use for it in their repository, so might not want it there. There is probably a mechanism to have Ubuntu specific patches on top of the debian ones.

This patch procedure is probably described in the link you gave, so I'll have to read that more carefully. Contributing to Ubuntu packages is new to me, so I don't feel comfortable to commit to that yet, but I'm inclined to give it a try (if time permits).

Attached is a debdiff that fixes CVE-2021-22204 on libimage-exiftool-perl 11.88-1; dch automatically changed the version to 11.88-1ubuntu1.

I simply checked out https://salsa.debian.org/perl-team/modules/packages/libimage-exiftool-perl/-/tree/debian/11.88-1 , cherry-picked https://salsa.debian.org/perl-team/modules/packages/libimage-exiftool-perl/-/commit/0347501fda93cb8366d6451aedcf258b34fb4a2b with the fix, and based the changelog on https://salsa.debian.org/perl-team/modules/packages/libimage-exiftool-perl/-/commit/5f175b3bb7db706cf840d8ee0f292a64e0abfae2 .

The changes can be found in my forked project: https://gitlab.com/hugobuddel/libimage-exiftool-perl/-/tree/hb/fix-CVE-2021-22204

It works, and it is a rather simple patch. Yet this is the first time I've ever build an Ubuntu package, so please check.

Also, I've added my name to the changelog, even though @gregoa Gregor Herrmann did the actual work, which is credited in the changelog. I don't care about getting credit for this, so feel free to change the changelog.

There are also several other Ubuntu versions listed as "Needs triage" on https://ubuntu.com/security/CVE-2021-22204 (21.04, 20.10, 18.04). I don't have those running, so I cannot comment on those.

Following https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue , I can now subscribe ubuntu-security-sponsors :

1. Your patch is in debdiff format

It is.

2. The patch follows the security team update procedures. Especially:

- targeted against the security pocket of a stable release

I think so, but I'm not exactly sure what a "security pocket" is. This is a patch against 20.04 LTS to fix an arbitrary code execution, so it seems appropriate.

I've updated the patch to have 'focal-security' as distribution, as described in https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging.

- uses the correct version

The version 11.88-1ubuntu1 is created by dch, so I'm assuming it is correct. (Maybe it should be 11.88-1ubuntu0.1 ?)

- mentions a CVE, and preferably a LP bug #.

The diff mentions CVE-2021-22204 and (LP: #1925985), which is this bug.

- Check your .changes file to make sure that you have the right revision and distribution

I've put 'focal-security' as distribution, which seemed the most appropriate.

3. All changes in the patch are intentional

They are.

4. Your patch applies cleanly

It does.

5. The Status and Assignment are correct

I cannot change the status, but it seems OK.

6. Please comment on the testing performed.

I've tested the patched package with echo_vakzz.jpg from https://hackerone.com/reports/1154542 on a development workstation. (So not on a clean Ubuntu installation.)

- If all of the above is in order, please subscribe ubuntu-security-sponsors

OK.

On Wed, 09 Jun 2021 19:37:15 -0000, Hugo Buddelmeijer wrote:

> Also, I've added my name to the changelog, even though @gregoa Gregor
> Herrmann did the actual work, which is credited in the changelog. I
> don't care about getting credit for this, so feel free to change the
> changelog.

FWIW, I'm perfectly fine with your changelog.

Great that you found our packaging repo on salsa and were able to
create a (hopefully) finished debdiff for Ubuntu.

> There are also several other Ubuntu versions listed as "Needs triage" on
> https://ubuntu.com/security/CVE-2021-22204 (21.04, 20.10, 18.04). I
> don't have those running, so I cannot comment on those.

In any case, the patch / upstream code change should apply for older
versions as well.

Cheers,
gregor

--
 .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-

This bug was fixed in the package libimage-exiftool-perl - 12.16+dfsg-1ubuntu0.1

---------------
libimage-exiftool-perl (12.16+dfsg-1ubuntu0.1) hirsute-security; urgency=medium

  * SECURITY UPDATE: Arbitrary code execution
    - debian/patches/CVE-2021-22204.patch: Improper neutralization of user
      data in the DjVu file format in ExifTool versions 7.44 and up allows
      arbitrary code execution when parsing the malicious image. (LP: #1925985)
      Thanks to William Bowling for the bug report on Launchpad.
      Thanks to Gregor Herrmann for backporting the patch.
      From debian release 12.16+dfsg-2.
    - CVE-2021-22204

 -- hugo buddelmeijer <email address hidden> Wed, 09 Jun 2021 20:39:41 +0200

This bug was fixed in the package libimage-exiftool-perl - 12.05-1ubuntu0.1

---------------
libimage-exiftool-perl (12.05-1ubuntu0.1) groovy-security; urgency=medium

  * SECURITY UPDATE: Arbitrary code execution
    - debian/patches/CVE-2021-22204.patch: Improper neutralization of user
      data in the DjVu file format in ExifTool versions 7.44 and up allows
      arbitrary code execution when parsing the malicious image. (LP: #1925985)
      Thanks to William Bowling for the bug report on Launchpad.
      Thanks to Gregor Herrmann for backporting the patch.
      From debian release 12.16+dfsg-2.
    - CVE-2021-22204

 -- hugo buddelmeijer <email address hidden> Wed, 09 Jun 2021 20:39:41 +0200

This bug was fixed in the package libimage-exiftool-perl - 11.88-1ubuntu0.1

---------------
libimage-exiftool-perl (11.88-1ubuntu0.1) focal-security; urgency=medium

  * SECURITY UPDATE: Arbitrary code execution
    - debian/patches/CVE-2021-22204.patch: Improper neutralization of user
      data in the DjVu file format in ExifTool versions 7.44 and up allows
      arbitrary code execution when parsing the malicious image. (LP: #1925985)
      Thanks to William Bowling for the bug report on Launchpad.
      Thanks to Gregor Herrmann for backporting the patch.
      From debian release 12.16+dfsg-2.
    - CVE-2021-22204

 -- hugo buddelmeijer <email address hidden> Wed, 09 Jun 2021 20:39:41 +0200

This bug was fixed in the package libimage-exiftool-perl - 10.80-1ubuntu0.1

---------------
libimage-exiftool-perl (10.80-1ubuntu0.1) bionic-security; urgency=medium

  * SECURITY UPDATE: Arbitrary code execution
    - debian/patches/CVE-2021-22204.patch: Improper neutralization of user
      data in the DjVu file format in ExifTool versions 7.44 and up allows
      arbitrary code execution when parsing the malicious image. (LP: #1925985)
      Thanks to William Bowling for the bug report on Launchpad.
      Thanks to Gregor Herrmann for backporting the patch.
      From debian release 12.16+dfsg-2.
    - CVE-2021-22204

 -- hugo buddelmeijer <email address hidden> Wed, 09 Jun 2021 20:39:41 +0200

Hello Hugo, Thanks for the help! I've published your backport for bionic, focal, groovy, and hirsute. The changelog was a little different to be in the format that we use. About the version number, we use major numbers (like ubuntu1) when is a devel release otherwise we increment the minor number (like I did, ubuntu0.1). Thanks!

Thanks Alex, Paulo and Gregor. Great to have this released!

And thanks for the learning opportunity. As in, my help probably didn't actually save you any time in the short run, because the only thing I effectively did was change the changelog of the upstream patch, and you had to redo that anyway because I wasn't experienced enough. But next time I'd know how to proceed.

About the versioning, I wasn't really sure, because https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging says 0.1, but I did not recall ever seeing such a package version, and dch automatically put 1 there. In retrospect I had all the information to conclude it should have been 0.1 though.

Because I must say that the documentation is very well done. It was way easier to figure everything out than expected. (I had never used dch, debuild or debdiff before.) The full documentation is enormous, and the SecurityTeam wiki pages distill it to the essential which is much appreciated.

The links to 'debdiff' are broken though, and I do not know where to report those, so I'll add them here: both https://wiki.ubuntu.com/SponsorshipProcess and https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue link to https://packaging.ubuntu.com/html/traditional-packaging.html#creating-a-debdiff , which does not exist.