perlsec.pod

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

going to turn around and execute some other program that is dependent on
your PATH, it makes sure you set the PATH.

The PATH isn't the only environment variable which can cause problems.
Because some shells may use the variables IFS, CDPATH, ENV, and
BASH_ENV, Perl checks that those are either empty or untainted when
starting subprocesses. You may wish to add something like this to your
setid and taint-checking scripts.

    delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};   # Make %ENV safer

It's also possible to get into trouble with other operations that don't
care whether they use tainted values.  Make judicious use of the file
tests in dealing with any user-supplied filenames.  When possible, do
opens and such B<after> properly dropping any special user (or group!)
privileges. Perl doesn't prevent you from opening tainted filenames for reading,
so be careful what you print out.  The tainting mechanism is intended to
prevent stupid mistakes, not to remove the need for thought.

Perl does not call the shell to expand wild cards when you pass C<system>
and C<exec> explicit parameter lists instead of strings with possible shell
wildcards in them.  Unfortunately, the C<open>, C<glob>, and
backtick functions provide no such alternate calling convention, so more
subterfuge will be required.

Perl provides a reasonably safe way to open a file or pipe from a setuid
or setgid program: just create a child process with reduced privilege who
does the dirty work for you.  First, fork a child using the special
C<open> syntax that connects the parent and child by a pipe.  Now the
child resets its ID set and any other per-process attributes, like
environment variables, umasks, current working directories, back to the
originals or known safe values.  Then the child process, which no longer
has any special permissions, does the C<open> or other system call.
Finally, the child passes the data it managed to access back to the
parent.  Because the file or pipe was opened in the child while running
under less privilege than the parent, it's not apt to be tricked into
doing something it shouldn't.

Here's a way to do backticks reasonably safely.  Notice how the C<exec> is
not called with a string that the shell could expand.  This is by far the
best way to call something that might be subjected to shell escapes: just
never call the shell at all.  

        use English '-no_match_vars';
        die "Can't fork: $!" unless defined($pid = open(KID, "-|"));
        if ($pid) {           # parent
            while (<KID>) {
                # do something
            }
            close KID;
        } else {
            my @temp     = ($EUID, $EGID);
            my $orig_uid = $UID;
            my $orig_gid = $GID;
            $EUID = $UID;
            $EGID = $GID;
            # Drop privileges
            $UID  = $orig_uid;
            $GID  = $orig_gid;
            # Make sure privs are really gone
            ($EUID, $EGID) = @temp;
            die "Can't drop privileges"
                unless $UID == $EUID  && $GID eq $EGID;
            $ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
	    # Consider sanitizing the environment even more.
            exec 'myprog', 'arg1', 'arg2'
                or die "can't exec myprog: $!";
        }

A similar strategy would work for wildcard expansion via C<glob>, although
you can use C<readdir> instead.

Taint checking is most useful when although you trust yourself not to have
written a program to give away the farm, you don't necessarily trust those
who end up using it not to try to trick it into doing something bad.  This
is the kind of security checking that's useful for set-id programs and
programs launched on someone else's behalf, like CGI programs.

This is quite different, however, from not even trusting the writer of the
code not to try to do something evil.  That's the kind of trust needed
when someone hands you a program you've never seen before and says, "Here,
run this."  For that kind of safety, check out the Safe module,
included standard in the Perl distribution.  This module allows the
programmer to set up special compartments in which all system operations
are trapped and namespace access is carefully controlled.

=head2 Security Bugs

Beyond the obvious problems that stem from giving special privileges to
systems as flexible as scripts, on many versions of Unix, set-id scripts
are inherently insecure right from the start.  The problem is a race
condition in the kernel.  Between the time the kernel opens the file to
see which interpreter to run and when the (now-set-id) interpreter turns
around and reopens the file to interpret it, the file in question may have
changed, especially if you have symbolic links on your system.

Fortunately, sometimes this kernel "feature" can be disabled.
Unfortunately, there are two ways to disable it.  The system can simply
outlaw scripts with any set-id bit set, which doesn't help much.
Alternately, it can simply ignore the set-id bits on scripts.  If the
latter is true, Perl can emulate the setuid and setgid mechanism when it
notices the otherwise useless setuid/gid bits on Perl scripts.  It does
this via a special executable called F<suidperl> that is automatically
invoked for you if it's needed.

However, if the kernel set-id script feature isn't disabled, Perl will
complain loudly that your set-id script is insecure.  You'll need to
either disable the kernel set-id script feature, or put a C wrapper around
the script.  A C wrapper is just a compiled program that does nothing
except call your Perl program.   Compiled programs are not subject to the
kernel bug that plagues set-id scripts.  Here's a simple wrapper, written
in C:

    #define REAL_PATH "/path/to/script"
    main(ac, av)
	char **av;
    {
	execv(REAL_PATH, av);
    }

Compile this wrapper into a binary executable and then make I<it> rather
than your script setuid or setgid.

In recent years, vendors have begun to supply systems free of this
inherent security bug.  On such systems, when the kernel passes the name
of the set-id script to open to the interpreter, rather than using a
pathname subject to meddling, it instead passes I</dev/fd/3>.  This is a
special file already opened on the script, so that there can be no race
condition for evil scripts to exploit.  On these systems, Perl should be
compiled with C<-DSETUID_SCRIPTS_ARE_SECURE_NOW>.  The F<Configure>
program that builds Perl tries to figure this out for itself, so you
should never have to specify this yourself.  Most modern releases of
SysVr4 and BSD 4.4 use this approach to avoid the kernel race condition.

Prior to release 5.6.1 of Perl, bugs in the code of F<suidperl> could
introduce a security hole.

=head2 Protecting Your Programs

There are a number of ways to hide the source to your Perl programs,
with varying levels of "security".

First of all, however, you I<can't> take away read permission, because
the source code has to be readable in order to be compiled and
interpreted.  (That doesn't mean that a CGI script's source is
readable by people on the web, though.)  So you have to leave the
permissions at the socially friendly 0755 level.  This lets 
people on your local system only see your source.

Some people mistakenly regard this as a security problem.  If your program does
insecure things, and relies on people not knowing how to exploit those
insecurities, it is not secure.  It is often possible for someone to
determine the insecure things and exploit them without viewing the
source.  Security through obscurity, the name for hiding your bugs
instead of fixing them, is little security indeed.

You can try using encryption via source filters (Filter::* from CPAN,
or Filter::Util::Call and Filter::Simple since Perl 5.8).
But crackers might be able to decrypt it.  You can try using the byte
code compiler and interpreter described below, but crackers might be
able to de-compile it.  You can try using the native-code compiler
described below, but crackers might be able to disassemble it.  These
pose varying degrees of difficulty to people wanting to get at your
code, but none can definitively conceal it (this is true of every
language, not just Perl).

If you're concerned about people profiting from your code, then the
bottom line is that nothing but a restrictive licence will give you
legal security.  License your software and pepper it with threatening
statements like "This is unpublished proprietary software of XYZ Corp.
Your access to it does not give you permission to use it blah blah
blah."  You should see a lawyer to be sure your licence's wording will
stand up in court.

=head2 Unicode

Unicode is a new and complex technology and one may easily overlook
certain security pitfalls.  See L<perluniintro> for an overview and
L<perlunicode> for details, and L<perlunicode/"Security Implications
of Unicode"> for security implications in particular.

=head2 Algorithmic Complexity Attacks

Certain internal algorithms used in the implementation of Perl can
be attacked by choosing the input carefully to consume large amounts
of either time or space or both.  This can lead into the so-called
I<Denial of Service> (DoS) attacks.

=over 4

=item *

Hash Function - the algorithm used to "order" hash elements has been
changed several times during the development of Perl, mainly to be
reasonably fast.  In Perl 5.8.1 also the security aspect was taken
into account.

In Perls before 5.8.1 one could rather easily generate data that as
hash keys would cause Perl to consume large amounts of time because
internal structure of hashes would badly degenerate.  In Perl 5.8.1
the hash function is randomly perturbed by a pseudorandom seed which
makes generating such naughty hash keys harder.
See L<perlrun/PERL_HASH_SEED> for more information.

The random perturbation is done by default but if one wants for some
reason emulate the old behaviour one can set the environment variable
PERL_HASH_SEED to zero (or any other integer).  One possible reason
for wanting to emulate the old behaviour is that in the new behaviour
consecutive runs of Perl will order hash keys differently, which may
confuse some applications (like Data::Dumper: the outputs of two
different runs are no more identical).

B<Perl has never guaranteed any ordering of the hash keys>, and the
ordering has already changed several times during the lifetime of
Perl 5.  Also, the ordering of hash keys has always been, and
continues to be, affected by the insertion order.

Also note that while the order of the hash elements might be
randomised, this "pseudoordering" should B<not> be used for
applications like shuffling a list randomly (use List::Util::shuffle()
for that, see L<List::Util>, a standard core module since Perl 5.8.0;
or the CPAN module Algorithm::Numerical::Shuffle), or for generating
permutations (use e.g. the CPAN modules Algorithm::Permute or
Algorithm::FastPermute), or for any cryptographic applications.

=item *

Regular expressions - Perl's regular expression engine is so called NFA
(Non-deterministic Finite Automaton), which among other things means that
it can rather easily consume large amounts of both time and space if the
regular expression may match in several ways.  Careful crafting of the
regular expressions can help but quite often there really isn't much
one can do (the book "Mastering Regular Expressions" is required
reading, see L<perlfaq2>).  Running out of space manifests itself by
Perl running out of memory.

=item *

Sorting - the quicksort algorithm used in Perls before 5.8.0 to
implement the sort() function is very easy to trick into misbehaving
so that it consumes a lot of time.  Nothing more is required than
resorting a list already sorted.  Starting from Perl 5.8.0 a different
sorting algorithm, mergesort, is used.  Mergesort is insensitive to
its input data, so it cannot be similarly fooled.

=back

See L<http://www.cs.rice.edu/~scrosby/hash/> for more information,
and any computer science textbook on the algorithmic complexity.

=head1 SEE ALSO

L<perlrun> for its description of cleaning up environment variables.