The Java world had an… interesting weekend when security researchers revealed on December 9 a vulnerability in the popular Apache Log4j 2 software library for recording and debugging events. Systems as diverse as Amazon Web Services, Apple iCloud, and the Minecraft video game could be exploited to run arbitrary code on a server merely by sending a specially-crafted string of text. Information technology professionals have been scrambling ever since the initial disclosure to patch, upgrade, reconfigure, or otherwise protect affected servers. It’s bad, and past unpatched vulnerabilities like this have been responsible for the exposure of millions of people’s sensitive data.
Many Perl applications use the similarly-named and ‑designed Log::Log4perl library, and the good news is that as far as I can tell the latter doesn’t suffer from the type of vulnerability described above. This doesn’t mean poorly-written or ‑configured Perl-based systems are immune to all exploits, just this particular one. You should be safe to continue using Log4perl unless someone has deliberately configured it otherwise, and in fact, my work uses it extensively.
You might be surprised to read me suggesting a logging framework after writing multiple articles espousing the Perl step debugger as an alternative. Log4perl developer Mike Schilli’s 2002 introduction to the package for Perl.com came down on the opposite side of the argument. It can seem like one of those programmer religious issues like tabs vs. spaces, vim vs. Emacs, or Linux vs. Windows. (For the record, the correct answers are spaces, BBEdit, and macOS. 😉)
But in this case, you can and should have the best of both worlds—logging at different levels to appropriate destinations while still dropping into the interactive debugger when you need to do something trickier like examine program state or tweak a data structure on the fly. I use both techniques and only emphasize the advocacy of step debugging because it’s understood less.
Comments
4 responses to “A brief note on Log4perl”
Can you prove ‑b that claim?
Log4perl is based on Log4j 1.x; the JNDI feature that is the basis for the Log4shell vulnerability was introduced in Log4j 2.x. Log4perl has no facility for downloading or running code from the network or otherwise evaluating user-supplied input unless you deliberately extend it to do that. Although it does have a facility for embedding Perl in its configuration file for filters or custom placeholders, you would again have to deliberately write those to evaluate user-supplied input. And if you do embed Perl in Log4perl’s configuration, you can and should explicitly specify which Perl opcodes and variables are allowed within the limited Safe compartment used to execute it.
[…] into one of the logging modules on CPAN like Log::Log4perl (not to be confused with that lately-problematic Java library), Log::Dispatch (which can be wired into Log4perl), or something else to suit […]
[…] looking into one of the logging modules on CPAN like Log::Log4perl (not to be confused with that lately-problematic Java library), Log::Dispatch (which can be wired into Log4perl), or something else to suit your […]