Privilege escalation through perl environment variables

In the ever-evolving landscape of cybersecurity, it’s crucial to stay vigilant and informed about potential vulnerabilities that could compromise the security of your systems. In this blog post, we’ll delve into a lesser-known but potent security issue involving Perl environment variables and how they can be exploited to escalate privilege. Understanding this threat is essential for system administrators and developers to protect their systems effectively.

Understanding the perl environment variables

Perl, which is a versatile and powerful scripting language, finds it’s way in many applications. Now generally which scripts/applications execute, they have some environment variables set through which they can get info of the variables set in the system.

Perl, like many scripting languages, relies on environment variables for various configuration and behavior modifications. In this context, we will focus on two particular environment variables: PERL5OPT and PERL5DB.

According to the Perl documentation, PERL5OPT is used to specify default command-line switches for Perl. It's an intriguing feature to explore further, as it offers us the ability to influence how Perl behaves by setting certain command-line options by default. This seemingly innocuous capability can be a powerful tool in the hands of a knowledgeable user or, in some cases, an attacker.

Let’s delve deeper into how PERL5OPT can be leveraged for both legitimate and potentially malicious purposes.

perl --help

Usage: perl [switches] [--] [programfile] [arguments]
  -0[octal]         specify record separator (\0, if no argument)
  -a                autosplit mode with -n or -p (splits $_ into @F)
  -C[number/list]   enables the listed Unicode features
  -c                check syntax only (runs BEGIN and CHECK blocks)
  -d[:debugger]     run program under debugger
  -D[number/list]   set debugging flags (argument is a bit mask or alphabets)
  -e program        one line of program (several -e's allowed, omit programfile)
  -E program        like -e, but enables all optional features
  -f                don't do $sitelib/sitecustomize.pl at startup
  -F/pattern/       split() pattern for -a switch (//'s are optional)
  -i[extension]     edit <> files in place (makes backup if extension supplied)
  -Idirectory       specify @INC/#include directory (several -I's allowed)
  -l[octal]         enable line ending processing, specifies line terminator
  -[mM][-]module    execute "use/no module..." before executing program
  -n                assume "while (<>) { ... }" loop around program
  -p                assume loop like -n but print line also, like sed
  -s                enable rudimentary parsing for switches after programfile
  -S                look for programfile using PATH environment variable
  -t                enable tainting warnings
  -T                enable tainting checks
  -u                dump core after parsing program
  -U                allow unsafe operations
  -v                print version, patchlevel and license
  -V[:variable]     print configuration summary (or a single Config.pm variable)
  -w                enable many useful warnings
  -W                enable all warnings
  -x[directory]     ignore text before #!perl line (optionally cd to directory)
  -X                disable all warnings
  
Run 'perldoc perl' for more help with Perl.

Here we can see the -d flag runs program under debugger.

Now if we take a look at PERL5DB variable, we clearly see

The command used to load the debugger code.

Now for the sake of testing this, let’s assume a user has some following privileges

In the context where monitor.sh serves as a system resource monitoring tool, a critical vulnerability comes to light: users possess the ability to set environment variables without the need for a sudo password. This oversight becomes the key to leveraging the variables discussed earlier in our exploitation strategy.

Initially, it’s evident that the SUID bit is not enabled on /bin/bash. However, as we execute the script, supplying specific variables, a remarkable transformation occurs: the SUID bit is discreetly set, opening the gateway to a root shell.

Conclusion

Understanding the security risks associated with Perl environment variables is crucial for maintaining a secure computing environment. By following best practices in input validation, access control, and user privileges, you can significantly reduce the likelihood of falling victim to privilege escalation attacks. Stay vigilant, stay informed, and keep your systems secure in the face of evolving threats.