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