1PERLSEC(1) Perl Programmers Reference Guide PERLSEC(1)
2
6 perlsec - Perl security
7
9 Perl is designed to make it easy to program securely even when running
10 with extra privileges, like setuid or setgid programs. Unlike most
11 command line shells, which are based on multiple substitution passes on
12 each line of the script, Perl uses a more conventional evaluation
13 scheme with fewer hidden snags. Additionally, because the language has
14 more builtin functionality, it can rely less upon external (and
15 possibly untrustworthy) programs to accomplish its purposes.
16
18 If you believe you have found a security vulnerability in the Perl
19 interpreter or modules maintained in the core Perl codebase, email the
20 details to perl-security@perl.org <mailto:perl-security@perl.org>.
21 This address is a closed membership mailing list monitored by the Perl
22 security team.
23 See perlsecpolicy for additional information.
25
27 Taint mode
28 By default, Perl automatically enables a set of special security
29 checks, called taint mode, when it detects its program running with
30 differing real and effective user or group IDs. The setuid bit in Unix
31 permissions is mode 04000, the setgid bit mode 02000; either or both
32 may be set. You can also enable taint mode explicitly by using the -T
33 command line flag. This flag is strongly suggested for server programs
34 and any program run on behalf of someone else, such as a CGI script.
35 Once taint mode is on, it's on for the remainder of your script.
36 While in this mode, Perl takes special precautions called taint checks
38 to prevent both obvious and subtle traps. Some of these checks are
39 reasonably simple, such as verifying that path directories aren't
40 writable by others; careful programmers have always used checks like
41 these. Other checks, however, are best supported by the language
42 itself, and it is these checks especially that contribute to making a
43 set-id Perl program more secure than the corresponding C program.
44 You may not use data derived from outside your program to affect
46 something else outside your program--at least, not by accident. All
47 command line arguments, environment variables, locale information (see
48 perllocale), results of certain system calls ("readdir()",
49 "readlink()", the variable of "shmread()", the messages returned by
50 "msgrcv()", the password, gcos and shell fields returned by the
51 "getpwxxx()" calls), and all file input are marked as "tainted".
52 Tainted data may not be used directly or indirectly in any command that
53 invokes a sub-shell, nor in any command that modifies files,
54 directories, or processes, with the following exceptions:
55 Support for taint checks adds an overhead to all Perl programs, whether
57 or not you're using the taint features. Perl 5.18 introduced C
58 preprocessor symbols that can be used to disable the taint features.
59 • Arguments to "print" and "syswrite" are not checked for
61 taintedness.
62 • Symbolic methods
64 $obj->$method(@args);
66 and symbolic sub references
68 &{$foo}(@args);
70 $foo->(@args);
71 are not checked for taintedness. This requires extra carefulness
73 unless you want external data to affect your control flow. Unless
74 you carefully limit what these symbolic values are, people are able
75 to call functions outside your Perl code, such as POSIX::system, in
76 which case they are able to run arbitrary external code.
77 • Hash keys are never tainted.
79 For efficiency reasons, Perl takes a conservative view of whether data
81 is tainted. If an expression contains tainted data, any subexpression
82 may be considered tainted, even if the value of the subexpression is
83 not itself affected by the tainted data.
84 Because taintedness is associated with each scalar value, some elements
86 of an array or hash can be tainted and others not. The keys of a hash
87 are never tainted.
88 For example:
90 $arg = shift; # $arg is tainted
92 $hid = $arg . 'bar'; # $hid is also tainted
93 $line = <>; # Tainted
94 $line = <STDIN>; # Also tainted
95 open FOO, "/home/me/bar" or die $!;
96 $line = <FOO>; # Still tainted
97 $path = $ENV{'PATH'}; # Tainted, but see below
98 $data = 'abc'; # Not tainted
99 system "echo $arg"; # Insecure
101 system "/bin/echo", $arg; # Considered insecure
102 # (Perl doesn't know about /bin/echo)
103 system "echo $hid"; # Insecure
104 system "echo $data"; # Insecure until PATH set
105 $path = $ENV{'PATH'}; # $path now tainted
107 $ENV{'PATH'} = '/bin:/usr/bin';
109 delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
110 $path = $ENV{'PATH'}; # $path now NOT tainted
112 system "echo $data"; # Is secure now!
113 open(FOO, "< $arg"); # OK - read-only file
115 open(FOO, "> $arg"); # Not OK - trying to write
116 open(FOO,"echo $arg|"); # Not OK
118 open(FOO,"-|")
119 or exec 'echo', $arg; # Also not OK
120 $shout = `echo $arg`; # Insecure, $shout now tainted
122 unlink $data, $arg; # Insecure
124 umask $arg; # Insecure
125 exec "echo $arg"; # Insecure
127 exec "echo", $arg; # Insecure
128 exec "sh", '-c', $arg; # Very insecure!
129 @files = <*.c>; # insecure (uses readdir() or similar)
131 @files = glob('*.c'); # insecure (uses readdir() or similar)
132 # In either case, the results of glob are tainted, since the list of
134 # filenames comes from outside of the program.
135 $bad = ($arg, 23); # $bad will be tainted
137 $arg, `true`; # Insecure (although it isn't really)
138 If you try to do something insecure, you will get a fatal error saying
140 something like "Insecure dependency" or "Insecure $ENV{PATH}".
141 The exception to the principle of "one tainted value taints the whole
143 expression" is with the ternary conditional operator "?:". Since code
144 with a ternary conditional
145 $result = $tainted_value ? "Untainted" : "Also untainted";
147 is effectively
149 if ( $tainted_value ) {
151 $result = "Untainted";
152 } else {
153 $result = "Also untainted";
154 }
155 it doesn't make sense for $result to be tainted.
157 Laundering and Detecting Tainted Data
159 To test whether a variable contains tainted data, and whose use would
160 thus trigger an "Insecure dependency" message, you can use the
161 "tainted()" function of the Scalar::Util module, available in your
162 nearby CPAN mirror, and included in Perl starting from the release
163 5.8.0. Or you may be able to use the following "is_tainted()"
164 function.
165 sub is_tainted {
167 local $@; # Don't pollute caller's value.
168 return ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
169 }
170 This function makes use of the fact that the presence of tainted data
172 anywhere within an expression renders the entire expression tainted.
173 It would be inefficient for every operator to test every argument for
174 taintedness. Instead, the slightly more efficient and conservative
175 approach is used that if any tainted value has been accessed within the
176 same expression, the whole expression is considered tainted.
177 But testing for taintedness gets you only so far. Sometimes you have
179 just to clear your data's taintedness. Values may be untainted by
180 using them as keys in a hash; otherwise the only way to bypass the
181 tainting mechanism is by referencing subpatterns from a regular
182 expression match. Perl presumes that if you reference a substring
183 using $1, $2, etc. in a non-tainting pattern, that you knew what you
184 were doing when you wrote that pattern. That means using a bit of
185 thought--don't just blindly untaint anything, or you defeat the entire
186 mechanism. It's better to verify that the variable has only good
187 characters (for certain values of "good") rather than checking whether
188 it has any bad characters. That's because it's far too easy to miss
189 bad characters that you never thought of.
190 Here's a test to make sure that the data contains nothing but "word"
192 characters (alphabetics, numerics, and underscores), a hyphen, an at
193 sign, or a dot.
194 if ($data =~ /^([-\@\w.]+)$/) {
196 $data = $1; # $data now untainted
197 } else {
198 die "Bad data in '$data'"; # log this somewhere
199 }
200 This is fairly secure because "/\w+/" doesn't normally match shell
202 metacharacters, nor are dot, dash, or at going to mean something
203 special to the shell. Use of "/.+/" would have been insecure in theory
204 because it lets everything through, but Perl doesn't check for that.
205 The lesson is that when untainting, you must be exceedingly careful
206 with your patterns. Laundering data using regular expression is the
207 only mechanism for untainting dirty data, unless you use the strategy
208 detailed below to fork a child of lesser privilege.
209 The example does not untaint $data if "use locale" is in effect,
211 because the characters matched by "\w" are determined by the locale.
212 Perl considers that locale definitions are untrustworthy because they
213 contain data from outside the program. If you are writing a locale-
214 aware program, and want to launder data with a regular expression
215 containing "\w", put "no locale" ahead of the expression in the same
216 block. See "SECURITY" in perllocale for further discussion and
217 examples.
218 Switches On the "#!" Line
220 When you make a script executable, in order to make it usable as a
221 command, the system will pass switches to perl from the script's #!
222 line. Perl checks that any command line switches given to a setuid (or
223 setgid) script actually match the ones set on the #! line. Some Unix
224 and Unix-like environments impose a one-switch limit on the #! line,
225 so you may need to use something like "-wU" instead of "-w -U" under
226 such systems. (This issue should arise only in Unix or Unix-like
227 environments that support #! and setuid or setgid scripts.)
228 Taint mode and @INC
230 +When the taint mode ("-T") is in effect, the environment variables
231 +"PERL5LIB", "PERLLIB", and "PERL_USE_UNSAFE_INC" are ignored by Perl.
232 You can still adjust @INC from outside the program by using the "-I"
233 command line option as explained in perlrun. The two environment
234 variables are ignored because they are obscured, and a user running a
235 program could be unaware that they are set, whereas the "-I" option is
236 clearly visible and therefore permitted.
237 Another way to modify @INC without modifying the program, is to use the
239 "lib" pragma, e.g.:
240 perl -Mlib=/foo program
242 The benefit of using "-Mlib=/foo" over "-I/foo", is that the former
244 will automagically remove any duplicated directories, while the latter
245 will not.
246 Note that if a tainted string is added to @INC, the following problem
248 will be reported:
249 Insecure dependency in require while running with -T switch
251 On versions of Perl before 5.26, activating taint mode will also remove
253 the current directory (".") from the default value of @INC. Since
254 version 5.26, the current directory isn't included in @INC by default.
255 Cleaning Up Your Path
257 For "Insecure $ENV{PATH}" messages, you need to set $ENV{'PATH'} to a
258 known value, and each directory in the path must be absolute and non-
259 writable by others than its owner and group. You may be surprised to
260 get this message even if the pathname to your executable is fully
261 qualified. This is not generated because you didn't supply a full path
262 to the program; instead, it's generated because you never set your PATH
263 environment variable, or you didn't set it to something that was safe.
264 Because Perl can't guarantee that the executable in question isn't
265 itself going to turn around and execute some other program that is
266 dependent on your PATH, it makes sure you set the PATH.
267 The PATH isn't the only environment variable which can cause problems.
269 Because some shells may use the variables IFS, CDPATH, ENV, and
270 BASH_ENV, Perl checks that those are either empty or untainted when
271 starting subprocesses. You may wish to add something like this to your
272 setid and taint-checking scripts.
273 delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; # Make %ENV safer
275 It's also possible to get into trouble with other operations that don't
277 care whether they use tainted values. Make judicious use of the file
278 tests in dealing with any user-supplied filenames. When possible, do
279 opens and such after properly dropping any special user (or group!)
280 privileges. Perl doesn't prevent you from opening tainted filenames
281 for reading, so be careful what you print out. The tainting mechanism
282 is intended to prevent stupid mistakes, not to remove the need for
283 thought.
284 Perl does not call the shell to expand wild cards when you pass
286 "system" and "exec" explicit parameter lists instead of strings with
287 possible shell wildcards in them. Unfortunately, the "open", "glob",
288 and backtick functions provide no such alternate calling convention, so
289 more subterfuge will be required.
290 Perl provides a reasonably safe way to open a file or pipe from a
292 setuid or setgid program: just create a child process with reduced
293 privilege who does the dirty work for you. First, fork a child using
294 the special "open" syntax that connects the parent and child by a pipe.
295 Now the child resets its ID set and any other per-process attributes,
296 like environment variables, umasks, current working directories, back
297 to the originals or known safe values. Then the child process, which
298 no longer has any special permissions, does the "open" or other system
299 call. Finally, the child passes the data it managed to access back to
300 the parent. Because the file or pipe was opened in the child while
301 running under less privilege than the parent, it's not apt to be
302 tricked into doing something it shouldn't.
303 Here's a way to do backticks reasonably safely. Notice how the "exec"
305 is not called with a string that the shell could expand. This is by
306 far the best way to call something that might be subjected to shell
307 escapes: just never call the shell at all.
308 use English;
310 die "Can't fork: $!" unless defined($pid = open(KID, "-|"));
311 if ($pid) { # parent
312 while (<KID>) {
313 # do something
314 }
315 close KID;
316 } else {
317 my @temp = ($EUID, $EGID);
318 my $orig_uid = $UID;
319 my $orig_gid = $GID;
320 $EUID = $UID;
321 $EGID = $GID;
322 # Drop privileges
323 $UID = $orig_uid;
324 $GID = $orig_gid;
325 # Make sure privs are really gone
326 ($EUID, $EGID) = @temp;
327 die "Can't drop privileges"
328 unless $UID == $EUID && $GID eq $EGID;
329 $ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
330 # Consider sanitizing the environment even more.
331 exec 'myprog', 'arg1', 'arg2'
332 or die "can't exec myprog: $!";
333 }
334 A similar strategy would work for wildcard expansion via "glob",
336 although you can use "readdir" instead.
337 Taint checking is most useful when although you trust yourself not to
339 have written a program to give away the farm, you don't necessarily
340 trust those who end up using it not to try to trick it into doing
341 something bad. This is the kind of security checking that's useful for
342 set-id programs and programs launched on someone else's behalf, like
343 CGI programs.
344 This is quite different, however, from not even trusting the writer of
346 the code not to try to do something evil. That's the kind of trust
347 needed when someone hands you a program you've never seen before and
348 says, "Here, run this." For that kind of safety, you might want to
349 check out the Safe module, included standard in the Perl distribution.
350 This module allows the programmer to set up special compartments in
351 which all system operations are trapped and namespace access is
352 carefully controlled. Safe should not be considered bullet-proof,
353 though: it will not prevent the foreign code to set up infinite loops,
354 allocate gigabytes of memory, or even abusing perl bugs to make the
355 host interpreter crash or behave in unpredictable ways. In any case
356 it's better avoided completely if you're really concerned about
357 security.
358 Shebang Race Condition
360 Beyond the obvious problems that stem from giving special privileges to
361 systems as flexible as scripts, on many versions of Unix, set-id
362 scripts are inherently insecure right from the start. The problem is a
363 race condition in the kernel. Between the time the kernel opens the
364 file to see which interpreter to run and when the (now-set-id)
365 interpreter turns around and reopens the file to interpret it, the file
366 in question may have changed, especially if you have symbolic links on
367 your system.
368 Some Unixes, especially more recent ones, are free of this inherent
370 security bug. On such systems, when the kernel passes the name of the
371 set-id script to open to the interpreter, rather than using a pathname
372 subject to meddling, it instead passes /dev/fd/3. This is a special
373 file already opened on the script, so that there can be no race
374 condition for evil scripts to exploit. On these systems, Perl should
375 be compiled with "-DSETUID_SCRIPTS_ARE_SECURE_NOW". The Configure
376 program that builds Perl tries to figure this out for itself, so you
377 should never have to specify this yourself. Most modern releases of
378 SysVr4 and BSD 4.4 use this approach to avoid the kernel race
379 condition.
380 If you don't have the safe version of set-id scripts, all is not lost.
382 Sometimes this kernel "feature" can be disabled, so that the kernel
383 either doesn't run set-id scripts with the set-id or doesn't run them
384 at all. Either way avoids the exploitability of the race condition,
385 but doesn't help in actually running scripts set-id.
386 If the kernel set-id script feature isn't disabled, then any set-id
388 script provides an exploitable vulnerability. Perl can't avoid being
389 exploitable, but will point out vulnerable scripts where it can. If
390 Perl detects that it is being applied to a set-id script then it will
391 complain loudly that your set-id script is insecure, and won't run it.
392 When Perl complains, you need to remove the set-id bit from the script
393 to eliminate the vulnerability. Refusing to run the script doesn't in
394 itself close the vulnerability; it is just Perl's way of encouraging
395 you to do this.
396 To actually run a script set-id, if you don't have the safe version of
398 set-id scripts, you'll need to put a C wrapper around the script. A C
399 wrapper is just a compiled program that does nothing except call your
400 Perl program. Compiled programs are not subject to the kernel bug
401 that plagues set-id scripts. Here's a simple wrapper, written in C:
402 #include <unistd.h>
404 #include <stdio.h>
405 #include <string.h>
406 #include <errno.h>
407 #define REAL_PATH "/path/to/script"
409 int main(int argc, char **argv)
411 {
412 execv(REAL_PATH, argv);
413 fprintf(stderr, "%s: %s: %s\n",
414 argv[0], REAL_PATH, strerror(errno));
415 return 127;
416 }
417 Compile this wrapper into a binary executable and then make it rather
419 than your script setuid or setgid. Note that this wrapper isn't doing
420 anything to sanitise the execution environment other than ensuring that
421 a safe path to the script is used. It only avoids the shebang race
422 condition. It relies on Perl's own features, and on the script itself
423 being careful, to make it safe enough to run the script set-id.
424 Protecting Your Programs
426 There are a number of ways to hide the source to your Perl programs,
427 with varying levels of "security".
428 First of all, however, you can't take away read permission, because the
430 source code has to be readable in order to be compiled and interpreted.
431 (That doesn't mean that a CGI script's source is readable by people on
432 the web, though.) So you have to leave the permissions at the socially
433 friendly 0755 level. This lets people on your local system only see
434 your source.
435 Some people mistakenly regard this as a security problem. If your
437 program does insecure things, and relies on people not knowing how to
438 exploit those insecurities, it is not secure. It is often possible for
439 someone to determine the insecure things and exploit them without
440 viewing the source. Security through obscurity, the name for hiding
441 your bugs instead of fixing them, is little security indeed.
442 You can try using encryption via source filters (Filter::* from CPAN,
444 or Filter::Util::Call and Filter::Simple since Perl 5.8). But crackers
445 might be able to decrypt it. You can try using the byte code compiler
446 and interpreter described below, but crackers might be able to de-
447 compile it. You can try using the native-code compiler described
448 below, but crackers might be able to disassemble it. These pose
449 varying degrees of difficulty to people wanting to get at your code,
450 but none can definitively conceal it (this is true of every language,
451 not just Perl).
452 If you're concerned about people profiting from your code, then the
454 bottom line is that nothing but a restrictive license will give you
455 legal security. License your software and pepper it with threatening
456 statements like "This is unpublished proprietary software of XYZ Corp.
457 Your access to it does not give you permission to use it blah blah
458 blah." You should see a lawyer to be sure your license's wording will
459 stand up in court.
460 Unicode
462 Unicode is a new and complex technology and one may easily overlook
463 certain security pitfalls. See perluniintro for an overview and
464 perlunicode for details, and "Security Implications of Unicode" in
465 perlunicode for security implications in particular.
466 Algorithmic Complexity Attacks
468 Certain internal algorithms used in the implementation of Perl can be
469 attacked by choosing the input carefully to consume large amounts of
470 either time or space or both. This can lead into the so-called Denial
471 of Service (DoS) attacks.
472 • Hash Algorithm - Hash algorithms like the one used in Perl are well
474 known to be vulnerable to collision attacks on their hash function.
475 Such attacks involve constructing a set of keys which collide into
476 the same bucket producing inefficient behavior. Such attacks often
477 depend on discovering the seed of the hash function used to map the
478 keys to buckets. That seed is then used to brute-force a key set
479 which can be used to mount a denial of service attack. In Perl
480 5.8.1 changes were introduced to harden Perl to such attacks, and
481 then later in Perl 5.18.0 these features were enhanced and
482 additional protections added.
483 At the time of this writing, Perl 5.18.0 is considered to be well-
485 hardened against algorithmic complexity attacks on its hash
486 implementation. This is largely owed to the following measures
487 mitigate attacks:
488 Hash Seed Randomization
490 In order to make it impossible to know what seed to generate an
491 attack key set for, this seed is randomly initialized at
492 process start. This may be overridden by using the
493 PERL_HASH_SEED environment variable, see "PERL_HASH_SEED" in
494 perlrun. This environment variable controls how items are
495 actually stored, not how they are presented via "keys",
496 "values" and "each".
497 Hash Traversal Randomization
499 Independent of which seed is used in the hash function, "keys",
500 "values", and "each" return items in a per-hash randomized
501 order. Modifying a hash by insertion will change the iteration
502 order of that hash. This behavior can be overridden by using
503 "hash_traversal_mask()" from Hash::Util or by using the
504 PERL_PERTURB_KEYS environment variable, see "PERL_PERTURB_KEYS"
505 in perlrun. Note that this feature controls the "visible"
506 order of the keys, and not the actual order they are stored in.
507 Bucket Order Perturbance
509 When items collide into a given hash bucket the order they are
510 stored in the chain is no longer predictable in Perl 5.18.
511 This has the intention to make it harder to observe a
512 collision. This behavior can be overridden by using the
513 PERL_PERTURB_KEYS environment variable, see "PERL_PERTURB_KEYS"
514 in perlrun.
515 New Default Hash Function
517 The default hash function has been modified with the intention
518 of making it harder to infer the hash seed.
519 Alternative Hash Functions
521 The source code includes multiple hash algorithms to choose
522 from. While we believe that the default perl hash is robust to
523 attack, we have included the hash function Siphash as a fall-
524 back option. At the time of release of Perl 5.18.0 Siphash is
525 believed to be of cryptographic strength. This is not the
526 default as it is much slower than the default hash.
527 Without compiling a special Perl, there is no way to get the exact
529 same behavior of any versions prior to Perl 5.18.0. The closest
530 one can get is by setting PERL_PERTURB_KEYS to 0 and setting the
531 PERL_HASH_SEED to a known value. We do not advise those settings
532 for production use due to the above security considerations.
533 Perl has never guaranteed any ordering of the hash keys, and the
535 ordering has already changed several times during the lifetime of
536 Perl 5. Also, the ordering of hash keys has always been, and
537 continues to be, affected by the insertion order and the history of
538 changes made to the hash over its lifetime.
539 Also note that while the order of the hash elements might be
541 randomized, this "pseudo-ordering" should not be used for
542 applications like shuffling a list randomly (use
543 "List::Util::shuffle()" for that, see List::Util, a standard core
544 module since Perl 5.8.0; or the CPAN module
545 "Algorithm::Numerical::Shuffle"), or for generating permutations
546 (use e.g. the CPAN modules "Algorithm::Permute" or
547 "Algorithm::FastPermute"), or for any cryptographic applications.
548 Tied hashes may have their own ordering and algorithmic complexity
550 attacks.
551 • Regular expressions - Perl's regular expression engine is so called
553 NFA (Non-deterministic Finite Automaton), which among other things
554 means that it can rather easily consume large amounts of both time
555 and space if the regular expression may match in several ways.
556 Careful crafting of the regular expressions can help but quite
557 often there really isn't much one can do (the book "Mastering
558 Regular Expressions" is required reading, see perlfaq2). Running
559 out of space manifests itself by Perl running out of memory.
560 • Sorting - the quicksort algorithm used in Perls before 5.8.0 to
562 implement the sort() function was very easy to trick into
563 misbehaving so that it consumes a lot of time. Starting from Perl
564 5.8.0 a different sorting algorithm, mergesort, is used by default.
565 Mergesort cannot misbehave on any input.
566 See
568 <https://www.usenix.org/legacy/events/sec03/tech/full_papers/crosby/crosby.pdf>
569 for more information, and any computer science textbook on algorithmic
570 complexity.
571 Using Sudo
573 The popular tool "sudo" provides a controlled way for users to be able
574 to run programs as other users. It sanitises the execution environment
575 to some extent, and will avoid the shebang race condition. If you
576 don't have the safe version of set-id scripts, then "sudo" may be a
577 more convenient way of executing a script as another user than writing
578 a C wrapper would be.
579 However, "sudo" sets the real user or group ID to that of the target
581 identity, not just the effective ID as set-id bits do. As a result,
582 Perl can't detect that it is running under "sudo", and so won't
583 automatically take its own security precautions such as turning on
584 taint mode. Where "sudo" configuration dictates exactly which command
585 can be run, the approved command may include a "-T" option to perl to
586 enable taint mode.
587 In general, it is necessary to evaluate the suitability of a script to
589 run under "sudo" specifically with that kind of execution environment
590 in mind. It is neither necessary nor sufficient for the same script to
591 be suitable to run in a traditional set-id arrangement, though many of
592 the issues overlap.
593
595 "ENVIRONMENT" in perlrun for its description of cleaning up environment
596 variables.
597perl v5.36.3 2023-11-30 PERLSEC(1)