The Perl Steering Committee has recently identified and patched two new major vulnerabilities that affect the Perl core, both of which make it possible for hackers to execute malicious code. While perl.org has made available patched recent versions of Perl (v5.34, v5.36 and v5.38), older versions are also affected, increasing the risk of running any version of Perl prior to v5.34.

For this reason, ActiveState has taken the initiative to backport the security fixes for these vulnerabilities as far back as Perl v5.22. More on this later.

First, let’s examine each vulnerability:

CVE-2023-47038

This vulnerability is defined simply as “write past buffer end via illegal user-defined Unicode property,” but it’s a problem that can arise when a well-crafted regular expression causes the Perl interpreter to overflow a section of memory, potentially causing undefined behavior, including crashes or other exploitable behavior.

In other words, this attack can corrupt or crash your program. Combined with another unknown or potential vulnerability in Perl or a library running with Perl, it may be possible for a dedicated attacker to execute malicious code remotely.

You can trigger this vulnerability by executing a regular expression with a custom user-defined character property embedded in it. Imagine if you were to take untrusted input from a user or file on your system, and then use that input as part of a regular expression. For example:if ($input =~ /\p{ExploitNamespace::IsExploit}/) { … }

You can eliminate the problem by: 

  • Avoiding this construct within your code (it’s not very common) 
  • Not allowing users to provide unmodified input used within regular expressions in your application, or within Perl libraries used by your application.

CVE-2023-47039

This vulnerability is defined simply as a Perl for Windows binary hijacking vulnerability, where, in certain situations, an attacker may be able to convince a Perl program running on Windows to execute a malicious program in an unsecure directory in order to exfiltrate data, open a connection to a malicious external system, overwrite data, infect your network, etc.

The problem arises because Perl for Windows relies on the system path environment variable to find the shell (`cmd.exe`), but defaults to looking for cmd.exe in the current working directory. An attacker who has permission to create a file in the working directory can place a file named cmd.exe there. If Perl attempts to use this command to execute shell commands, Perl will execute the attacker’s file.

To trigger this vulnerability: 

  1. An attacker needs access to a directory that your Perl application will use. This means the attacker needs access to the machine running Perl, or a network drive your Perl application will access. 
  2. Your program needs to execute Windows commands which trigger the execution of the malicious cmd.exe.

Perl Zero Day Solutions for ActiveState Customers

ActiveState has been supporting Perl for more than twenty years, originally via our legacy prebuilt distributions (ActivePerl Community Edition) and now via our more secure and up-to-date ActiveState Perl. 

To ensure you can continue working with a secure version of Perl, ActiveState users have a number of choices: 

  • ActiveState Perl Customers – log into the ActiveState Platform and download the patched Perl versions for v5.32 through v5.38 for all supported OS’s (Windows, Mac, Linux).
  • ActivePerl Customers – if you’ve previously downloaded a Community Edition ActivePerl installer and you are concerned about these CVEs, contact us about obtaining a fix for v5.22 through v5.28.

For other Perl users that are worried about the security risks associated with running EOL versions of Perl, ActiveState is introducing an extended support offering that can help mitigate the risk.

Perl EOL Extended Support

As one of the first and most popular interpreted languages, Perl was extensively used in the enterprise during the 1990’s and 2000’s. While not as popular today, many enterprises continue to maintain a large amount of legacy Perl code they cannot readily sunset, easily upgrade to a new version of Perl, or cost-effectively migrate to a new programming language. 

As the list of unsupported versions of Perl continues to grow, the risks associated with running legacy Perl is growing, as well. The snapshot of supported vs unsupported Perl versions currently includes:

ReleaseCommunity SupportCommunity Security PatchesActiveState EOL Extended Support
5.38 (July 2023)YesEnds July 2026Starts Q3 2026
5.36 (May 2022)YesEnds May 2025Starts Q2 2025
5.34 (May 2021)Ended May 2022Ends May 2024Starts Q2 2024
5.32 (June 2020)Ended May 2022Ended June 2023Ongoing
5.30 (May 2019)Ended May 2021Ended May 2022N/A*
5.28 (June 2018)Ended June 2020Ended June 2021Ends Q4 2024
5.26 (May 2017)Ended May 2019Ended May 2020Ends Q4 2024
5.24 (May 2016)Ended May 2018Ended May 2019Ends Q4 2023
5.22 (June 2015)Ended June 2017Ended June 2018Ends Q4 2023

* ActiveState never created a Perl 5.30 release

As the table also shows, ActiveState continues to provide security updates for many versions of the Perl core language beyond the community EOL date. An ActiveState EOL support subscription entitles you to:

  • Core Language – support for the features and functionality of the core Perl language and standard libraries.
  • Patches – vulnerabilities will be addressed with backported patches from community supported versions of Perl, community contributors, and our own Perl experts.
  • Other Security Issues – issues identified exclusively in a version of Perl will be fixed by ActiveState in conjunction with community contributors.
  • Scheduled Updates – patches and updates will be made available on at least a quarterly basis. Critical vulnerability patches may be provided on a more timely basis.
  • Ongoing Support – communicate with our Perl experts via phone, email and chat.

Next Steps

Whether you require support during your upgrade process, or have decided to continue running an EOL version of Perl, contact us to see how ActiveState can help.