Insecurities from Symbolic Function References and Prevention

Perl Insecurities and Prevention – Part 6

Perl Course

Foreword: In this part of the series, I talk about Insecurities from Symbolic Function References and Prevention.

By: Chrysanthus Date Published: 23 Nov 2015

Introduction

This is part 6 of my series, Perl Insecurities and Prevention. In this part of the series, I talk about Insecurities from Symbolic Function References and Prevention. You should have read the previous parts of the series before coming here, as this is a continuation.

There are two types of symbolic function references: symbolic sub references and symbolic methods. In each case, a function code is attached to a reference variable. The reference variable may originally be a function reference (code reference) variable, an object (hash) reference variable, an array reference variable or even a scalar reference variable.

The problem is: it is legitimate in Perl, for a function code to be attached to a reference different from its original function reference; and for a reference to be attached to a function code different from its original function code. As you can see, hackers are ready to take advantage of this. I will spend the rest of the tutorial explaining the phenomenon, the hacking problem and then the prevention. I begin with symbolic sub references before I go to object methods.

Symbolic Sub References
Symbolic sub references are of the form:

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

In either of these cases, $FOO is holding a reference to the same function code.

In the following program, there are two code references for two different function bodies, assigned to two different variables. Each function body has its own reference. Below in the program, the references interchange variables.

use strict;

    my $coderefA = sub
            {
                print "I am originally of reference A.\n";
            };

    my $coderefB = sub
            {
                print "I am originally of reference B.\n";
            };

    my $temp = $coderefA;
    $coderefA = $coderefB;  #$coderefA now holds reference (memory address) of B
    $coderefB = $temp;  #$coderefB now holds reference (memory address) of A

    &$coderefA();  #function call
    &$coderefB();

The output is:

    I am originally of reference B.
    I am originally of reference A.

opposite to what was originally coded. In the following program a variable is given a new reference (address) and function body and evaluated on behalf of the first function body. Try the code and when asked for the input, type and press Enter, the following:

    sub {print "Thank you. I am danger!"};

The program is:

use strict;

    my $coderef = sub
                     {
                        print "I am the right variable Body.";
                     };

    my $input = <STDIN>;

    $coderef = eval $input;

    &$coderef();  #function call

The output is:

    Thank you. I am danger!

So, if the hacker can know the variable names, $coderef and $input, which are difficult, but not impossible to know, he can send in false code to your program, through the eval() function. In the following program, the hacker uses a variable in the program to execute a function in a module.

Assume that you have the following module:

package Pack;

sub fn
    {
        print "I am a killer.";
    }

1;

Assume that your program is:

use strict;

use Pack;

    my $coderef = sub
                     {
                        print "I am the right variable Body.";
                     };

    my $input = <STDIN>;

    eval "$coderef = $input";

    &$coderef();

If the input is,

    \&Pack::fn()

then the output will be:

    I am a killer.I am the right variable Body.

The input is a reference to a function in the module.

The hacker can easily know the variables of a module, because documents of modules are not hidden (they are all-over the web). If he struggles and knows the variable, $coderef, then he can send in wrong code through the eval() function.

Symbolic Methods
An example of a symbolic method is:

    $obj->method(@args);

Assume that you have the following module with a constructor and one method:

package Pack;

       sub new
            {
                bless {};
            }

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

Assume that you have the following Perl program:

use strict;

use Pack "meth";

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

    my $newObj;

    my $input = <STDIN>;

    $newObj = eval $input;

    $newObj->meth();

    print "$_ " foreach @arr;

If you execute the Perl program with the following input,

    bless \@arr, 'Pack'

then the output will be:

   sheep trouble cow

So, through the eval() function, the hacker has used an array blessed object to call a method in a module for a hash object of the module. The hacker can always know the names of the module and its methods. If the hacker can know the variable, $newObj, then he would be able to send in wrong code to the program, using the eval function.

Prevention
Prevention for symbolic sub references and symbolic methods are as follows:

- code these features with a lot of care, because you yourself can make mistakes;
- validate all inputs;
- do not use a module that you do not trust;
- avoid using the eval() function or do not use it at all.

Note: it is possible to integrate the namespace of a module with the namespace of the main program.

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

Chrys

Broad Network

Related Articles

Insecurities from Symbolic Function References and Prevention

Perl Insecurities and Prevention – Part 6

Perl Course

Introduction

Related Links

Comments