Strawberry Perl Update

[aerk]

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?

[obetz]

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?

[aerk]

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/

[Phil Harvey]

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

[aerk]

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.

[lyricos]

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.

[Phil Harvey]

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

[obetz]

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.

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

If 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.

[aerk]

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?

[obetz]

been 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.

[obetz]

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.

[aerk]

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

[lyricos]

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.

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

If 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.

[Phil Harvey]

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

[Martin B.]

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