[Bug 3838] Insecure dependency in eval while running setuid

[bu...@bugzilla.spamassassin.org]

http://bugzilla.spamassassin.org/show_bug.cgi?id=3838





------- Additional Comments From Mark.Martinec@ijs.si  2005-09-05 10:17 -------
Please get rid of perl 5.8.0 first, and try with 5.8.2 or later. 
 
There are lots of problems with 5.8.0, including buggy taint processing. 
Later versions have some of these problems fixed, but not all, so an 
application running in taint mode needs to provide some workarounds 
for these. It is not worth the effort trying to fix an application 
to work on Perl 5.8.0 if it works properly with later versions. 
 
One of the most annoying taint bugs in Perl (still present even in 
versions beyond 5.8.2) is that during certain regexp evaluations, 
global variables like $1, $2, $3, ... become tainted out of thin air. 
This has far-fetched consequences, as from such a point on, a classical 
untaint operation like: $str=$1 if $str=~/^(.*)\z/ no longer works 
as untaint, because $1 somehow got stuck with a taint flag. 
 
I have been fighting with these in amavisd-new (which calls SA) 
for the last year and more. I had to use dozens of workarounds for 
taint bugs. Luckily a usual workaround is available in a form 
of making $1 etc. local, e.g.: 
 
  { local($1,$2,$3,$4,$5,$6);  # avoid Perl 5.8.0 bug, $1 gets tainted 
    $per_msg_status = $spamassassin_obj->check($mail_obj); 
  } 
 
or: 
  { local($1,$2,$3,$4);  # avoid Perl 5.8.0..5.8.3...? taint bug 
    $spam_level  = $per_msg_status->get_hits; 
    $spam_report = $per_msg_status->get_report;  # taints $1 and $2 ! 
   } 
 
Tainting or $1, $2, ... occurs also in core Perl modules, triggered 
by certain more complex expressions (like chained s/// || s/// || ..), 
so one can never be sure that the $1 won't become tainted from an 
innocent looking operation like IO::File::open. 
 
>From amavisd-new release notes, July 2004: 
- opened another can of Perl worms (taint bugs): turn on Perl pragma 
  "use re 'taint'" in all modules, and selectively turn it off where needed. 
  It replaces cumbersome manual preservation of taintedness when regexp 
  saved ranges are used without intention to untaint. Because of Perl bugs, 
  strategically placed local($1,$2,...) are needed, otherwise previous 
  taint flag in $1, $2, ... can be brought on to new variables, which can 
  all of a sudden become tainted out of nowhere; 
 
>From amavisd-new release notes, April 2004: 
- when calling IO::File::open() use '+>' instead of 'w+' to avoid 
  Perl taint bug ($mode turns tainted) (bug still present in 5.8.2) 
  triggered by expression in IO::Handle::_open_mode_string(); 
 
- attack the Perl 5.8.0/5.8.1/5.8.3 taint bug (once variables $1,$2,etc 
  get tainted they start spreading taintedness to other variables): 
  * insert local($1,$2,$3,...) in blocks of code which call external 
    modules which trigger the bug (Mail::SpamAssasin, MIME::Parser, ...) 
  * insert local($1,$2,$3,...) in blocks of code which depend on these 
    variables to be clean, and which demonstrated through bug reports 
    and experience with various version of Perl that these variables 
    were not always taint-clean; 
  The last taint incident triggered by SA 3.0.0 (svn) reported by Luc de Louw 
 
My 'best practices' recommendation is to: 
- use local($1) or local($1,$2,$3,...as needed) around every regexp match 
  which produces results in these global variables; 
- use  use re 'taint'; in all modules to prevent inadvertent untaining; 
- explicitly untaint with a subroutine such as: 
 
# Return untainted copy of a string (argument can be a string or a string ref) 
sub untaint($) { 
  no re 'taint'; 
  my($str); 
  if (defined($_[0])) { 
    local($1); # avoid Perl taint bug: tainted global $1 propagates taintedness 
    $str = $1  if (ref($_[0]) ? ${$_[0]} : $_[0]) =~ /^(.*)\z/s; 
  } 
  $str; 
} 
 
 
Good luck. 
  Mark 
 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.