Commit | Line | Data |
---|---|---|
a0d0e21e LW |
1 | =head1 NAME |
2 | ||
3 | perlsec - Perl security | |
4 | ||
5 | =head1 DESCRIPTION | |
6 | ||
425e5e39 | 7 | Perl is designed to make it easy to program securely even when running |
8 | with extra privileges, like setuid or setgid programs. Unlike most | |
54310121 | 9 | command line shells, which are based on multiple substitution passes on |
425e5e39 | 10 | each line of the script, Perl uses a more conventional evaluation scheme |
11 | with fewer hidden snags. Additionally, because the language has more | |
54310121 | 12 | builtin functionality, it can rely less upon external (and possibly |
425e5e39 | 13 | untrustworthy) programs to accomplish its purposes. |
a0d0e21e | 14 | |
425e5e39 | 15 | Perl automatically enables a set of special security checks, called I<taint |
16 | mode>, when it detects its program running with differing real and effective | |
17 | user or group IDs. The setuid bit in Unix permissions is mode 04000, the | |
18 | setgid bit mode 02000; either or both may be set. You can also enable taint | |
5f05dabc | 19 | mode explicitly by using the B<-T> command line flag. This flag is |
425e5e39 | 20 | I<strongly> suggested for server programs and any program run on behalf of |
fb73857a | 21 | someone else, such as a CGI script. Once taint mode is on, it's on for |
22 | the remainder of your script. | |
a0d0e21e | 23 | |
1e422769 | 24 | While in this mode, Perl takes special precautions called I<taint |
25 | checks> to prevent both obvious and subtle traps. Some of these checks | |
26 | are reasonably simple, such as verifying that path directories aren't | |
27 | writable by others; careful programmers have always used checks like | |
28 | these. Other checks, however, are best supported by the language itself, | |
fb73857a | 29 | and it is these checks especially that contribute to making a set-id Perl |
425e5e39 | 30 | program more secure than the corresponding C program. |
31 | ||
fb73857a | 32 | You may not use data derived from outside your program to affect |
33 | something else outside your program--at least, not by accident. All | |
34 | command line arguments, environment variables, locale information (see | |
35 | L<perllocale>), results of certain system calls (readdir, readlink, | |
36 | the gecos field of getpw* calls), and all file input are marked as | |
37 | "tainted". Tainted data may not be used directly or indirectly in any | |
38 | command that invokes a sub-shell, nor in any command that modifies | |
a3cb178b GS |
39 | files, directories, or processes. (B<Important exception>: If you pass |
40 | a list of arguments to either C<system> or C<exec>, the elements of | |
41 | that list are B<NOT> checked for taintedness.) Any variable set | |
fb73857a | 42 | to a value derived from tainted data will itself be tainted, |
43 | even if it is logically impossible for the tainted data | |
44 | to alter the variable. Because taintedness is associated with each | |
a034a98d | 45 | scalar value, some elements of an array can be tainted and others not. |
a0d0e21e | 46 | |
a0d0e21e LW |
47 | For example: |
48 | ||
425e5e39 | 49 | $arg = shift; # $arg is tainted |
50 | $hid = $arg, 'bar'; # $hid is also tainted | |
51 | $line = <>; # Tainted | |
8ebc5c01 | 52 | $line = <STDIN>; # Also tainted |
53 | open FOO, "/home/me/bar" or die $!; | |
54 | $line = <FOO>; # Still tainted | |
a0d0e21e | 55 | $path = $ENV{'PATH'}; # Tainted, but see below |
425e5e39 | 56 | $data = 'abc'; # Not tainted |
a0d0e21e | 57 | |
425e5e39 | 58 | system "echo $arg"; # Insecure |
59 | system "/bin/echo", $arg; # Secure (doesn't use sh) | |
60 | system "echo $hid"; # Insecure | |
61 | system "echo $data"; # Insecure until PATH set | |
a0d0e21e | 62 | |
425e5e39 | 63 | $path = $ENV{'PATH'}; # $path now tainted |
a0d0e21e | 64 | |
54310121 | 65 | $ENV{'PATH'} = '/bin:/usr/bin'; |
c90c0ff4 | 66 | delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'}; |
a0d0e21e | 67 | |
425e5e39 | 68 | $path = $ENV{'PATH'}; # $path now NOT tainted |
69 | system "echo $data"; # Is secure now! | |
a0d0e21e | 70 | |
425e5e39 | 71 | open(FOO, "< $arg"); # OK - read-only file |
72 | open(FOO, "> $arg"); # Not OK - trying to write | |
a0d0e21e | 73 | |
425e5e39 | 74 | open(FOO,"echo $arg|"); # Not OK, but... |
75 | open(FOO,"-|") | |
76 | or exec 'echo', $arg; # OK | |
a0d0e21e | 77 | |
425e5e39 | 78 | $shout = `echo $arg`; # Insecure, $shout now tainted |
a0d0e21e | 79 | |
425e5e39 | 80 | unlink $data, $arg; # Insecure |
81 | umask $arg; # Insecure | |
a0d0e21e | 82 | |
425e5e39 | 83 | exec "echo $arg"; # Insecure |
84 | exec "echo", $arg; # Secure (doesn't use the shell) | |
85 | exec "sh", '-c', $arg; # Considered secure, alas! | |
a0d0e21e | 86 | |
7bac28a0 | 87 | @files = <*.c>; # Always insecure (uses csh) |
88 | @files = glob('*.c'); # Always insecure (uses csh) | |
89 | ||
a0d0e21e | 90 | If you try to do something insecure, you will get a fatal error saying |
62f468fc | 91 | something like "Insecure dependency" or "Insecure $ENV{PATH}". Note that you |
425e5e39 | 92 | can still write an insecure B<system> or B<exec>, but only by explicitly |
a3cb178b | 93 | doing something like the "considered secure" example above. |
425e5e39 | 94 | |
95 | =head2 Laundering and Detecting Tainted Data | |
96 | ||
97 | To test whether a variable contains tainted data, and whose use would thus | |
fb73857a | 98 | trigger an "Insecure dependency" message, check your nearby CPAN mirror |
99 | for the F<Taint.pm> module, which should become available around November | |
100 | 1997. Or you may be able to use the following I<is_tainted()> function. | |
425e5e39 | 101 | |
102 | sub is_tainted { | |
54310121 | 103 | return ! eval { |
104 | join('',@_), kill 0; | |
105 | 1; | |
425e5e39 | 106 | }; |
107 | } | |
108 | ||
109 | This function makes use of the fact that the presence of tainted data | |
110 | anywhere within an expression renders the entire expression tainted. It | |
111 | would be inefficient for every operator to test every argument for | |
112 | taintedness. Instead, the slightly more efficient and conservative | |
113 | approach is used that if any tainted value has been accessed within the | |
114 | same expression, the whole expression is considered tainted. | |
115 | ||
5f05dabc | 116 | But testing for taintedness gets you only so far. Sometimes you have just |
425e5e39 | 117 | to clear your data's taintedness. The only way to bypass the tainting |
54310121 | 118 | mechanism is by referencing subpatterns from a regular expression match. |
425e5e39 | 119 | Perl presumes that if you reference a substring using $1, $2, etc., that |
120 | you knew what you were doing when you wrote the pattern. That means using | |
121 | a bit of thought--don't just blindly untaint anything, or you defeat the | |
a034a98d DD |
122 | entire mechanism. It's better to verify that the variable has only good |
123 | characters (for certain values of "good") rather than checking whether it | |
124 | has any bad characters. That's because it's far too easy to miss bad | |
125 | characters that you never thought of. | |
425e5e39 | 126 | |
127 | Here's a test to make sure that the data contains nothing but "word" | |
128 | characters (alphabetics, numerics, and underscores), a hyphen, an at sign, | |
129 | or a dot. | |
130 | ||
54310121 | 131 | if ($data =~ /^([-\@\w.]+)$/) { |
425e5e39 | 132 | $data = $1; # $data now untainted |
133 | } else { | |
134 | die "Bad data in $data"; # log this somewhere | |
135 | } | |
136 | ||
5f05dabc | 137 | This is fairly secure because C</\w+/> doesn't normally match shell |
425e5e39 | 138 | metacharacters, nor are dot, dash, or at going to mean something special |
139 | to the shell. Use of C</.+/> would have been insecure in theory because | |
140 | it lets everything through, but Perl doesn't check for that. The lesson | |
141 | is that when untainting, you must be exceedingly careful with your patterns. | |
142 | Laundering data using regular expression is the I<ONLY> mechanism for | |
143 | untainting dirty data, unless you use the strategy detailed below to fork | |
144 | a child of lesser privilege. | |
145 | ||
a034a98d DD |
146 | The example does not untaint $data if C<use locale> is in effect, |
147 | because the characters matched by C<\w> are determined by the locale. | |
148 | Perl considers that locale definitions are untrustworthy because they | |
149 | contain data from outside the program. If you are writing a | |
150 | locale-aware program, and want to launder data with a regular expression | |
151 | containing C<\w>, put C<no locale> ahead of the expression in the same | |
152 | block. See L<perllocale/SECURITY> for further discussion and examples. | |
153 | ||
3a52c276 CS |
154 | =head2 Switches On the "#!" Line |
155 | ||
156 | When you make a script executable, in order to make it usable as a | |
157 | command, the system will pass switches to perl from the script's #! | |
54310121 | 158 | line. Perl checks that any command line switches given to a setuid |
3a52c276 | 159 | (or setgid) script actually match the ones set on the #! line. Some |
54310121 | 160 | Unix and Unix-like environments impose a one-switch limit on the #! |
3a52c276 | 161 | line, so you may need to use something like C<-wU> instead of C<-w -U> |
54310121 | 162 | under such systems. (This issue should arise only in Unix or |
163 | Unix-like environments that support #! and setuid or setgid scripts.) | |
3a52c276 | 164 | |
425e5e39 | 165 | =head2 Cleaning Up Your Path |
166 | ||
1fef88e7 | 167 | For "Insecure C<$ENV{PATH}>" messages, you need to set C<$ENV{'PATH'}> to a |
1e422769 | 168 | known value, and each directory in the path must be non-writable by others |
169 | than its owner and group. You may be surprised to get this message even | |
170 | if the pathname to your executable is fully qualified. This is I<not> | |
171 | generated because you didn't supply a full path to the program; instead, | |
172 | it's generated because you never set your PATH environment variable, or | |
173 | you didn't set it to something that was safe. Because Perl can't | |
174 | guarantee that the executable in question isn't itself going to turn | |
175 | around and execute some other program that is dependent on your PATH, it | |
54310121 | 176 | makes sure you set the PATH. |
a0d0e21e | 177 | |
a3cb178b GS |
178 | The PATH isn't the only environment variable which can cause problems. |
179 | Because some shells may use the variables IFS, CDPATH, ENV, and | |
180 | BASH_ENV, Perl checks that those are either empty or untainted when | |
181 | starting subprocesses. You may wish to add something like this to your | |
182 | setid and taint-checking scripts. | |
183 | ||
184 | delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; # Make %ENV safer | |
185 | ||
a0d0e21e LW |
186 | It's also possible to get into trouble with other operations that don't |
187 | care whether they use tainted values. Make judicious use of the file | |
188 | tests in dealing with any user-supplied filenames. When possible, do | |
fb73857a | 189 | opens and such B<after> properly dropping any special user (or group!) |
190 | privileges. Perl doesn't prevent you from opening tainted filenames for reading, | |
a0d0e21e LW |
191 | so be careful what you print out. The tainting mechanism is intended to |
192 | prevent stupid mistakes, not to remove the need for thought. | |
193 | ||
425e5e39 | 194 | Perl does not call the shell to expand wild cards when you pass B<system> |
195 | and B<exec> explicit parameter lists instead of strings with possible shell | |
196 | wildcards in them. Unfortunately, the B<open>, B<glob>, and | |
54310121 | 197 | backtick functions provide no such alternate calling convention, so more |
198 | subterfuge will be required. | |
425e5e39 | 199 | |
200 | Perl provides a reasonably safe way to open a file or pipe from a setuid | |
201 | or setgid program: just create a child process with reduced privilege who | |
202 | does the dirty work for you. First, fork a child using the special | |
203 | B<open> syntax that connects the parent and child by a pipe. Now the | |
204 | child resets its ID set and any other per-process attributes, like | |
205 | environment variables, umasks, current working directories, back to the | |
206 | originals or known safe values. Then the child process, which no longer | |
207 | has any special permissions, does the B<open> or other system call. | |
208 | Finally, the child passes the data it managed to access back to the | |
5f05dabc | 209 | parent. Because the file or pipe was opened in the child while running |
425e5e39 | 210 | under less privilege than the parent, it's not apt to be tricked into |
211 | doing something it shouldn't. | |
212 | ||
54310121 | 213 | Here's a way to do backticks reasonably safely. Notice how the B<exec> is |
425e5e39 | 214 | not called with a string that the shell could expand. This is by far the |
215 | best way to call something that might be subjected to shell escapes: just | |
fb73857a | 216 | never call the shell at all. |
cb1a09d0 | 217 | |
54310121 | 218 | use English; |
fb73857a | 219 | die "Can't fork: $!" unless defined $pid = open(KID, "-|"); |
cb1a09d0 AD |
220 | if ($pid) { # parent |
221 | while (<KID>) { | |
222 | # do something | |
425e5e39 | 223 | } |
cb1a09d0 AD |
224 | close KID; |
225 | } else { | |
fb73857a | 226 | my @temp = ($EUID, $EGID); |
425e5e39 | 227 | $EUID = $UID; |
5a964f20 | 228 | $EGID = $GID; # initgroups() also called! |
fb73857a | 229 | # Make sure privs are really gone |
230 | ($EUID, $EGID) = @temp; | |
5a964f20 TC |
231 | die "Can't drop privileges" |
232 | unless $UID == $EUID && $GID eq $EGID; | |
425e5e39 | 233 | $ENV{PATH} = "/bin:/usr/bin"; |
5a964f20 TC |
234 | exec 'myprog', 'arg1', 'arg2' |
235 | or die "can't exec myprog: $!"; | |
425e5e39 | 236 | } |
237 | ||
fb73857a | 238 | A similar strategy would work for wildcard expansion via C<glob>, although |
239 | you can use C<readdir> instead. | |
425e5e39 | 240 | |
241 | Taint checking is most useful when although you trust yourself not to have | |
242 | written a program to give away the farm, you don't necessarily trust those | |
243 | who end up using it not to try to trick it into doing something bad. This | |
fb73857a | 244 | is the kind of security checking that's useful for set-id programs and |
425e5e39 | 245 | programs launched on someone else's behalf, like CGI programs. |
246 | ||
247 | This is quite different, however, from not even trusting the writer of the | |
248 | code not to try to do something evil. That's the kind of trust needed | |
249 | when someone hands you a program you've never seen before and says, "Here, | |
250 | run this." For that kind of safety, check out the Safe module, | |
251 | included standard in the Perl distribution. This module allows the | |
252 | programmer to set up special compartments in which all system operations | |
253 | are trapped and namespace access is carefully controlled. | |
254 | ||
255 | =head2 Security Bugs | |
256 | ||
257 | Beyond the obvious problems that stem from giving special privileges to | |
fb73857a | 258 | systems as flexible as scripts, on many versions of Unix, set-id scripts |
425e5e39 | 259 | are inherently insecure right from the start. The problem is a race |
260 | condition in the kernel. Between the time the kernel opens the file to | |
fb73857a | 261 | see which interpreter to run and when the (now-set-id) interpreter turns |
425e5e39 | 262 | around and reopens the file to interpret it, the file in question may have |
263 | changed, especially if you have symbolic links on your system. | |
264 | ||
265 | Fortunately, sometimes this kernel "feature" can be disabled. | |
266 | Unfortunately, there are two ways to disable it. The system can simply | |
fb73857a | 267 | outlaw scripts with any set-id bit set, which doesn't help much. |
268 | Alternately, it can simply ignore the set-id bits on scripts. If the | |
425e5e39 | 269 | latter is true, Perl can emulate the setuid and setgid mechanism when it |
270 | notices the otherwise useless setuid/gid bits on Perl scripts. It does | |
271 | this via a special executable called B<suidperl> that is automatically | |
54310121 | 272 | invoked for you if it's needed. |
425e5e39 | 273 | |
fb73857a | 274 | However, if the kernel set-id script feature isn't disabled, Perl will |
275 | complain loudly that your set-id script is insecure. You'll need to | |
276 | either disable the kernel set-id script feature, or put a C wrapper around | |
425e5e39 | 277 | the script. A C wrapper is just a compiled program that does nothing |
278 | except call your Perl program. Compiled programs are not subject to the | |
fb73857a | 279 | kernel bug that plagues set-id scripts. Here's a simple wrapper, written |
425e5e39 | 280 | in C: |
281 | ||
282 | #define REAL_PATH "/path/to/script" | |
54310121 | 283 | main(ac, av) |
425e5e39 | 284 | char **av; |
285 | { | |
286 | execv(REAL_PATH, av); | |
54310121 | 287 | } |
cb1a09d0 | 288 | |
54310121 | 289 | Compile this wrapper into a binary executable and then make I<it> rather |
290 | than your script setuid or setgid. | |
425e5e39 | 291 | |
292 | See the program B<wrapsuid> in the F<eg> directory of your Perl | |
293 | distribution for a convenient way to do this automatically for all your | |
294 | setuid Perl programs. It moves setuid scripts into files with the same | |
295 | name plus a leading dot, and then compiles a wrapper like the one above | |
296 | for each of them. | |
297 | ||
298 | In recent years, vendors have begun to supply systems free of this | |
299 | inherent security bug. On such systems, when the kernel passes the name | |
fb73857a | 300 | of the set-id script to open to the interpreter, rather than using a |
425e5e39 | 301 | pathname subject to meddling, it instead passes I</dev/fd/3>. This is a |
302 | special file already opened on the script, so that there can be no race | |
303 | condition for evil scripts to exploit. On these systems, Perl should be | |
304 | compiled with C<-DSETUID_SCRIPTS_ARE_SECURE_NOW>. The B<Configure> | |
305 | program that builds Perl tries to figure this out for itself, so you | |
306 | should never have to specify this yourself. Most modern releases of | |
307 | SysVr4 and BSD 4.4 use this approach to avoid the kernel race condition. | |
308 | ||
309 | Prior to release 5.003 of Perl, a bug in the code of B<suidperl> could | |
310 | introduce a security hole in systems compiled with strict POSIX | |
311 | compliance. | |
68dc0745 | 312 | |
313 | =head2 Protecting Your Programs | |
314 | ||
315 | There are a number of ways to hide the source to your Perl programs, | |
316 | with varying levels of "security". | |
317 | ||
318 | First of all, however, you I<can't> take away read permission, because | |
319 | the source code has to be readable in order to be compiled and | |
320 | interpreted. (That doesn't mean that a CGI script's source is | |
321 | readable by people on the web, though.) So you have to leave the | |
5a964f20 TC |
322 | permissions at the socially friendly 0755 level. This lets |
323 | people on your local system only see your source. | |
68dc0745 | 324 | |
5a964f20 | 325 | Some people mistakenly regard this as a security problem. If your program does |
68dc0745 | 326 | insecure things, and relies on people not knowing how to exploit those |
327 | insecurities, it is not secure. It is often possible for someone to | |
328 | determine the insecure things and exploit them without viewing the | |
329 | source. Security through obscurity, the name for hiding your bugs | |
330 | instead of fixing them, is little security indeed. | |
331 | ||
332 | You can try using encryption via source filters (Filter::* from CPAN). | |
333 | But crackers might be able to decrypt it. You can try using the | |
54310121 | 334 | byte code compiler and interpreter described below, but crackers might |
68dc0745 | 335 | be able to de-compile it. You can try using the native-code compiler |
336 | described below, but crackers might be able to disassemble it. These | |
337 | pose varying degrees of difficulty to people wanting to get at your | |
338 | code, but none can definitively conceal it (this is true of every | |
339 | language, not just Perl). | |
340 | ||
341 | If you're concerned about people profiting from your code, then the | |
342 | bottom line is that nothing but a restrictive licence will give you | |
343 | legal security. License your software and pepper it with threatening | |
344 | statements like "This is unpublished proprietary software of XYZ Corp. | |
345 | Your access to it does not give you permission to use it blah blah | |
346 | blah." You should see a lawyer to be sure your licence's wording will | |
347 | stand up in court. | |
5a964f20 TC |
348 | |
349 | =head1 SEE ALSO | |
350 | ||
351 | L<perlrun> for its description of cleaning up environment variables. |