[Bug 5645] New: Transition to explicit untainting in modules

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

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5645

           Summary: Transition to explicit untainting in modules
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Libraries
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: Mark.Martinec@ijs.si


The implicit untainting mechanism offered by Perl in a form
of regexp matching has its good and its undesired sides.
The good side is that in some cases it does the right thing
when a programmer is careful to use it carefully.
The down side is that regexp matching is also used for other
purposes, and the untainting action is more often than not
unintentional, leading to data laundering as a side effect,
defeating the taint checking safety net.

The SA module Util already provides routines for explicit
untainting of variables, but so far the untaint_var() has
only rarely been used. On the other front, Perl provides
a pragma (already in 5.6.1, possibly earlier):
   use re 'taint';
which allows turning off the implicit untainting.

Combining both offers us best of both worlds, allowing
a programmer to explicitly untaint data when required,
and avoid implicit untainting when just thinking of
program's functionality.

My current round of commits to trunk is providing this
transition. First some preparatory grounds has been laid down,
and the final stroke is placing a "use re 'taint'" in all
modules. Taking out the last step reverts to the traditional
behaviour, if a serious need arises.

I'll follow up with more comment, bear with me for few hours
(although all transitional steps keep code normally functional),
then you may shoot  :)



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

[Bug 5645] Transition to explicit untainting in modules

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

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5645


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From jm@jmason.org  2008-02-12 13:24 -------
it looks like this has been done; Mark, feel free to reopen otherwise.



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

[Bug 5645] Transition to explicit untainting in modules

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

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5645


Mark.Martinec@ijs.si changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Undefined                   |3.3.0




------- Additional Comments From Mark.Martinec@ijs.si  2007-09-11 12:29 -------
Ok, I've done what I had in mind. Self tests pass ok, it works fine from
a command line and under amavisd (Bayes@SQL, almost all plugins enabled).
I haven't tested with user-supplied rules and with spamd (besides self-test).

I intentionally avoided blind-untainting during parsing of a config file,
so that certain variables (e.g. rules, loadable module names, ...) now
remain tainted until the routine which knows what to expect and what is safe
to untaint. Letting tainted data propagate to a final consumer as much as
is practical, is a general policy to be followed here - is my suggestion.

This may smoke out some additional Perl taint bugs regarding the
global variables $1, $2, ... which sometimes get mysteriously tainted.
Localizing these variables is a good practice anyway (avoiding horrible
Perl practice to let subroutines use global temporary variables).
I already added local($1,$2,...) where I stumbled across; it is
possible that some more will be needed or desired.

If you come across some new taint problems in scenarios I haven't
tried, please let me know (or better still: fix them please).
Since 3.3.0 is not so close it seems, I believe this gives
plenty of time to possibly do some additional modifications
in the spirit of this change, and squash possible bugs.

Thanks for bearing with me! My goal is to gradually make
SpamAssassin more robust and easier to troubleshoot.



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