ExifTool Forum

A couple of CVEs has been discovered lately affecting older versions of Perl according to https://www.cvedetails.com/vulnerability-list/vendor_id-1885/Perl.html.

Would it be possible to update to the latest version of Strawberry Perl used by the Windows distribution of ExifTools?

I try to prepare a new environment, but it will take some time.

Which of the listed issues do you think affect current ExifTool versions and would be resolved by updating to Strawberry Perl 5.40.0.1?

I suspect that ExifTools could be vulnerable to the following three:

• https://www.cvedetails.com/cve/CVE-2023-47100/
• https://www.cvedetails.com/cve/CVE-2023-47038/
• https://www.cvedetails.com/cve/CVE-2023-47039/

The 2 regular expression vulnerabilities CVE-2023-47038 and CVE-2023-47100 shouldn't be an issue.  There are bigger problems if the ExifTool user is allowing untrusted regular expresions to be evaluated.  There shouldn't be any place in ExifTool where a regular expression from file metadata is evaluated.

And I don't think the cmd.exe path vulnerability CVE-2023-47039 is an issue because it occurs "When running an executable that uses the Windows Perl interpreter".  I assume that by this they mean shelling out to exec an external Perl script.  ExifTool doesn't do this.  It does exec some external commands, but none of them require Perl.

- Phil

Thanks for the detailed answer. I agree with your conclusion.

There seems to be no need to update to the latest Strawberry Perl from a security perspective.

Hello, just looking at this issue.  Although I can agree that the Perl CVEs do not specifically plague ExifTool, there's the problem that the Perl dependencies will now exist standalone on machines that run ExifTool, allowing bad actors to leverage that dependencies to accomplish more damage. 
If we were to deploy ExifTool with a compromised version of Perl, some customer's security policy will not allow it to be installed.

If this is a problem then the customer can always install whatever version of Perl suits them along with the pure Perl version of ExifTool (the .tar.gz package).

- Phil

Quote from: lyricos on March 07, 2025, 12:18:22 PMthere's the problem that the Perl dependencies will now exist standalone on machines that run ExifTool, allowing bad actors to leverage that dependencies to accomplish more damage.

can you describe the scenario how "bad actors" might "leverage that dependencies"? By running the Perl instance without ExifTool?

Quote from: lyricos on March 07, 2025, 12:18:22 PMIf we were to deploy ExifTool with a compromised version of Perl, some customer's security policy will not allow it to be installed.

I still can't follow.

So we have been getting a lot of questions lately from our users that are asking questions about why we use a vulnerable (although it should not affect ExifTool) version of Perl.

Would it be possible to upgrade to the latest version of Strawberry Perl in the official release just to stop them asking questions?

Quote from: aerk on March 11, 2025, 01:33:12 PMbeen getting a lot of questions

I see two requesters in this thread, did I miss others?

You stated "There seems to be no need to update to the latest Strawberry Perl from a security perspective" and lyricos didn't answer.

As I wrote, it's on my list, but I do extensive checks to assure no component is missing, and I currently have a lot of other work to do.

Well, again no answer.

Can anybody explain the different flavors of Perl?

• 5.40.0.1 dated 2024-08-10 GCC 13.2 with UCRT, only 64 bit, "latest release" on home page but not listed on https://strawberryperl.com/releases.html
• 5.38.2.2 dated 2023-12-11 latest download listed on https://strawberryperl.com/releases.html, only 64 bit, gcc-13.1, "same compiler toolchain as version 5.38.0.1 so will have the same UTF-8 locale issues" - as far as I see, it's gcc 13.1.0 MinGW-W64 with MSVCRT runtime
• 5.38.2.1 32 bit dated 2023-11-30, only on Github (not on strawberryperl.com), latest 32 bit version there
• 5.32.1.1 dated 2021-01-24 latest 32 bit download listed on https://strawberryperl.com/releases.html

I wonder what might be the reason that 5.38.2.1 32 bit is not listed on https://strawberryperl.com/releases.html and whether the 32 bit toolchain has also UTF-8 locale issues.

Hi, I meant that we do get questions from customers using our products.

There seems to be an open issue in perl that is blocking the win32 build at the moment.
https://github.com/Perl/perl5/issues/23022

Maybe it is better to wait this PR to get merged before attempting an upgrade.
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/pull/233

Quote from: obetz on March 07, 2025, 01:44:47 PM

Quote from: lyricos on March 07, 2025, 12:18:22 PMthere's the problem that the Perl dependencies will now exist standalone on machines that run ExifTool, allowing bad actors to leverage that dependencies to accomplish more damage.

can you describe the scenario how "bad actors" might "leverage that dependencies"? By running the Perl instance without ExifTool?

Quote from: lyricos on March 07, 2025, 12:18:22 PMIf we were to deploy ExifTool with a compromised version of Perl, some customer's security policy will not allow it to be installed.

I still can't follow.

The problem is similar to what aerk mentioned.  We bundle ExifTool as part of our application that we distribute to our customers. Because ExifTool currently ships with a version of Perl that has open CVEs, customer's security software can flag it and can question us why we are adding vulnerable files onto their machine.  The problem really has nothing to do with ExifTool itself.  The existence and usage of a vulnerable version of PERL is really the main concern.

You haven't mentioned what your application is for, but I suppose if it is a cybersecurity app then your customers may be more sensitive to this sort of thing.

- Phil

I'm using Image-ExifTool (the package, not the executable) and Perl 5.36 from ActiveState. No glitches and good customer support (even though I'm on a free plan). It also works with pp -M PAR (I know, there are better options, but I haven't tried them yet).

ActiveState offers source traceability, and they are up to date (Image-ExifTool 13.25 and Perl 5.38.3). They have free options for Open Source, but I don't think they have free options for use of their distribution commercially. Check their terms and conditions.

If your customers are very sensitive to cybersecurity, they should be open to pay extra for the trouble of frequently monitoring and updating the source code.

I hope this helps.

- Martin

Quote from: lyricos on March 17, 2025, 03:12:12 PMWe bundle ExifTool as part of our application that we distribute to our customers.

Then you might consider to bundle also a Perl version of your choice.

Or at least telling me which version you would prefer - see the limitations listed above.

Quote from: Martin B. on March 17, 2025, 06:55:18 PMI'm using Image-ExifTool (the package, not the executable) and Perl 5.36 from ActiveState. No glitches and good customer support (even though I'm on a free plan).

I failed to understand the ActiveState EULA, it seemed to be rather restrictive.

There doesn't seem to be any open CVEs for 5.38.2 or above. So either that or a newer version would work fine.

We only use the x64 version so it would be okay if the x86 is left as is or updated to another version.

Quote from: aerk on March 19, 2025, 02:56:25 AMThere doesn't seem to be any open CVEs for 5.38.2 or above. So either that or a newer version would work fine.

So you would accept the risk expressed in the comment "same compiler toolchain as version 5.38.0.1 so will have the same UTF-8 locale issues"?

I do not know how that impacts ExifTool so it is very difficult for me to answer.

I can't answer that either.

- Phil

So let me summarize:

• The status of Strawberry Perl releases is unclear.
• The licensing of ActiveState Perl is unclear, I don't dare to use it in a package.
• Any change has a risk of breaking something, for example trading "no CVE listed" for "UTF-8 locale issues".
• Perl 5.40 is still quite new. The fact that no CVE is listed does not mean that there is no vulnerability, it could just be unknown.

I would like the two requesters to weigh up the consequences well, taking into account that the new version must be useful for the general public and cannot address their specific requirements, and then make me a suggestion as to which Perl versions meet these requirements.