I came across an interesting point to meditate upon this evening while reading through the Perl source to some applications I had downloaded for review. I'll paste a slightly-edited snippet of the code, edited only to obscure its source, which piqued my thoughts:

#!/usr/bin/perl -w

.
.

# Do some things to make Taint happy:
delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};   # Make %ENV safer
$ENV{PATH} = '/bin:/usr/bin:/usr/local/bin';

.
.

my(%options);
getopts('nhkf:p:', \%options);
if($options{'k'}) {  # kill running program.
  my($pid) = `cat $HOME/program.pid`;
  if($pid =~ m{([0-9]+)}) { $pid = $1; }
  kill 'INT', $pid;
  exit(0);
}
[download]

Now what caught my interest with this code, was that while it appears it was written to execute under Perl with the taint (-T) and warnings (-w), it falls horribly short of the secure code that the author was obviously intent on producing. This code, designed to obtain the process ID of the current invocation of the application and terminate its execution, falls short on many levels.

Most notably, the code, while comments within it suggest it has been written to run under taint mode, has not been invocated as such - That is, the #!-shebang path to the Perl interpreter does not pass the -T taint switch. However beyond this, in the segment of code intended to actually obtain the process ID of the invoked application and kill it, major flaws in logic negate any worth which taint mode execution could offer.

  my($pid) = `cat $HOME/program.pid`;
  if($pid =~ m{([0-9]+)}) { $pid = $1; }
  kill 'INT', $pid;
  exit(0);
[download]

Firstly, this segment of code relies on an external application to return process ID of the application from the program.pid file in the application home directory. Now while this itself is not a crime, and I should note that the program author has cleaned up the environment path, it shifts the burden of responsibility off to the external application to return the correct value.

Furthermore, while the author had the foresight to check that the returned value is indeed a number, there is no check to see whether this is a valid process ID, the process ID of the invoked application (remember, the external file and application on which the dependency for this value has been placed may have been modified outside the bounds of our code logic) or indeed provided correct fall-through in the event of a maligned process ID being returned. Indeed, should one feel so inclined and depending on the execution rights of this code, which given the application could be priviledged, it would be relatively easy to turn this application into a tool for misdemeanour.

In short, the content of this meditation are thus

• Don't rely solely on taint to clean up your code - The major problems with this code and indeed as to why it most likely will not run cleanly under taint mode are related to programmer logic moreso than 'dirty' data.
• Think your code through, rationale and evaluate your logic and process flow and build your code accordingly.
• In the process of code development and debugging, taint is your ally, treat your ally as a friend, not an enemy.

Your thoughts and comments on the value and application of taint and programmer logic in securing code are welcomed.

 

 

Ooohhh, Rob no beer function well without!