Categories of Tainted Data Expressions in Perl

Perl Insecurities and Prevention – Part 2

Perl Course

Foreword: In this part of the series I talk about the categories of expressions, which a hacker can use to send in wrong data or wrong code into a Perl program.

By: Chrysanthus Date Published: 23 Nov 2015

Introduction

This is part 2 of my series, Perl Insecurities and Prevention. In this part of the series I talk about the categories of expressions, which a hacker can use to send in wrong data or wrong code into a Perl program. A Perl program is a Perl script. In this series, once a user sends successfully wrong data or wrong code into a Perl program, we say the program has been hacked. The consequences of the hacking, such as financial benefic, false information, knowing credentials or destruction of program flow and other ills, are not really addressed. In this series, you learn about insecure expressions and how to prevent them from being exploited by hackers. You should have read the previous part of the series before coming here, as this is a continuation.

Prevention of hacking can be summarized as follows: Wrong data or wrong code, should not enter a program. While wrong data or wrong code is in the program, it should not disrupt the program flow. Wrong data should not leave the program for other destinations, because of wrong data inputted or wrong code inputted.

Tainted
The verb, taint, means to damage or spoil the quality of something. Tainted, is the adjective. In Perl, I describe any expression that a hacker can use to cause damage as tainted. However, do not worry; in this series, you will learn tainted data expressions in Perl and also learn how to block them from being abused by hackers. A tainted expression is legitimate coding; you need to learn how to prevent them from being exploited by hackers. Untainting, means preventing an expression from being exploited by a hacker.

Tainted Data Expressions
Taintedness is associated with a scalar value. What is a value? A scalar variable can have a value, which is undef, a number, a string or a reference. An array consists of scalar values. A hash consists of keys and scalar values. If a function is identified by a reference variable, then the whole function code is a kind of value; actually, the reference is a value to the scalar variable.

In this section I give you the categories of tainted expressions in Perl:

- Scalar Value

- Hash

- Symbolic Sub References
Examples of symbolic functions are:

    &{$foo}(@args);
    $foo->(@args);

These are function calls with arguments, (@args), where the function name is a dereference of the function reference, not the direct function name itself.

- Symbolic Methods
An example of a symbolic method is:

    $obj->$method(@args);

These are methods from an object of Perl OOP, accessed by the object.

- eval Function

Compile Time and Run Time
When you code a Perl program and you execute it, there are two phases to the execution, which are compilation and running. When any Perl program is executed, there is a minimal compilation of the whole program before the running of the whole program. Compile time is when syntax errors are checked. Runtime is when the program receives input and sends output.

Brief Explanation of Tainted Data Expression
In this section, I give brief explanations of the tainted data expressions in Perl, and I also indicate prevention.

Scalar Value
A scalar valued coded (assigned to a variable) in the program, is not much of a problem. Problem comes with scalar values received as input from a user, input as command line arguments, input from environment variables, input as feedback result from system (operating system) calls such as readdir(), input as operating system password.

The way to prevent such input value from having wrong data or wrong code, is to validate the input. I talk about the details in a different part of the series.

Hash
A hash has key/value pairs. The values, even the keys can be changed directly, by statement modifiers (e.g. the foreach modifier), and conditional constructs (e.g. the while-loop). A hacker can figure this out (determine it) and through the various input ways, inject wrong data or wrong code to cause trouble. I will say more about the hash and prevention, in a later part of the series.

Symbolic Sub References
Examples of symbolic functions are:

    &{$foo}(@args);
    $foo->(@args);

In these two examples, &{$foo} or $foo-> is a dereference operation. In either of them $foo is holding the reference to the function. Either of the functions (subroutines) is called by using the reference to the function. This means, in each case, the function is a kind of value to the reference variable; actually, the reference is a value to the scalar variable. For these two examples, both calls are for the same function ($foo).

A hacker can figure out (determine) the variable, $foo, and replace the reference with a reference to a different function. This other function can be a function in your code; it can be a function in a module (library) that you are using; or it can be a function code sent into your code as ordinary input for an eval function.

As you can see, this is clearly dangerous. I will say more about symbolic sub references and prevention, in a later part of the series. Note that the hacker can just replace the code for the variable with, undef.

The reference to a function can be obtained in normal coding as follows:

    my $foo = sub
                        {
                            //statements
                        }

or as follows,

    sub name
                {
                    //statements
                }

    my $foo = \&name;

Symbolic Methods
An example of a symbolic method is:

    $obj->method(@args);

Now, $obj is a hash reference (a blessed reference). The functions of the class where method() resides, can be made to bless with a different variable other than $obj, and then used to cause trouble. Try the following code:

use strict;

    my @arr = ('sheep', 'chicken', 'cow');

    {package Pack;

        sub new
            {
                bless {};
            }

        sub meth
            {
                my $ObjRef = $_[0];
                $ObjRef->[1] = 'trouble';
            }

    }

    my $newObj = bless \@arr, 'Pack';

    $newObj->meth();

    print "$_ " foreach @arr;

The output is:

   sheep trouble cow

Your favorite flesh, which is chicken, in the array has been replaced with “trouble”. If the aim of this code were to place an order for chicken, you would place an order for trouble. This happens in the code, because it is not only the hash reference in the package that can be blessed with the methods of the package; the reference of any variable inside or outside the package can be blessed with the package.

I will say more about this and prevention, in a later part of the series.

eval Function
The two main syntaxes for the eval() function are:

eval EXPR

eval BLOCK;

Whether the argument to eval is EXP or BLOCK, the argument is code. It can be just a value. It can be a variable, and rather unfortunately, it can be statements separated by semicolons.

eval EXPR operates at runtime. So, if EXP is input at runtime, then any unsafe code can be injected. eval BLOCK may have argument values sent to it at runtime, or compile time values of scalar variables that have been changed at runtime.

I will say more about the eval function, and prevention, in a later part of the series.

A Hacker
The word, hacker, actually has two meanings: a good meaning and a bad meaning. In this series, it is the bad meaning we use for the word, hacker. A hacker can be somebody who has no permission for the Perl program. In this case his work is most difficult and he has to rely on operating system input to the program, network input to the program, environment variable input to the program, and input as feedback result from system calls.

If he has at least the read permission, his work becomes less difficult. If he has the read and execute permissions, his work becomes even less difficult. In Perl, unfortunately, every user of an executable Perl program must have both the read and executable permissions.

So, with Perl, a hacker may be a non-user of the program, or he may be a user who has some permissions to the program.

Never give the write permission to any user you do not trust. Because, if the person is a hacker, you open all the doors to him.

That is it for this part of the series. Let us stop here and continue in the next part.

Chrys

Broad Network

Related Articles

Categories of Tainted Data Expressions in Perl

Perl Insecurities and Prevention – Part 2

Perl Course

Introduction

Related Links

Comments