Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Taint mode limitations

by BrowserUk (Pope)
on Nov 02, 2012 at 17:11 UTC ( #1002011=note: print w/ replies, xml ) Need Help??


in reply to Taint mode limitations

when I first started reading about taint mode, I expected that it would identify every single instance of tainted variable and force me to look at it explicitly.

It does! What it cannot do -- which you seem to be expecting -- is decide whether you looked closely enough.

Think of it like front desk security issuing outsiders with a visitor's pass. If then you chose to leave them alone in the vault for a while, that is down to you.

  • When data comes in to your program from a (potentially) unsafe source it gets marked.
  • If you attempt to use that data before you've taken some action to validate it; Perl will yell at you.
  • But if Perl never allowed you to remove the mark; you would never be able to use that data.
  • And there is no way for Perl to determine whether what you have done has rendered that data "safe". Only you can make that decision.

So perl give you the tools; if you choose to use them incorrectly, that is down to you.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong


Comment on Re: Taint mode limitations
Re^2: Taint mode limitations
by alain_desilets (Beadle) on Nov 03, 2012 at 13:10 UTC
    when I first started reading about taint mode, I expected that it would identify every single instance of tainted variable and force me to look at it explicitly.
    It does! What it cannot do -- which you seem to be expecting -- is decide whether you looked closely enough.

    I understand that it's my responsability to make sure I have looked at the input closely enough. My issue is that Perl tries to "guess" when I have looked at the the input ("gee, the programmer captured some match groups from a regexp match on that input, so it MUST mean that he sanitized it"), instead of letting me tell it when I think I have looked at it closely enough (for example, but invoking a method untainted() on a variable).

    Using your front desk metaphor, suppose I am a security guard patrolling the corridors of a building. As I go through the front gate in the morning, I notice my front desk colleague making eye contact with a visitor. Later on, I see this visitor wandering the corridors without a pass. Can I assume that this visitor is authorized just because my colleague made eye contact with him? No, of course not!

      My issue is that Perl tries to "guess" when I have looked at the the input ("gee, the programmer captured some match groups from a regexp match on that input, so it MUST mean that he sanitized it"), instead of letting me tell it when I think I have looked at it closely enough (for example, but invoking a method untainted() on a variable).

      Perl isn't "guessing". It is following the clearly laid out rule for 'detainting'. That is:

      Perl presumes that if you reference a substring using $1, $2, etc., that you knew what you were doing when you wrote the pattern.

      And it goes on to say:

      That means using a bit of thought--don't just blindly untaint anything, or you defeat the entire mechanism.

      That may not be how you think it should work; but it is the way it does work. For better or worse.

      You can try putting forwards your arguments for a different -- presumably better in your eyes -- way of working; but given how long the current mechanism has been in place; that the mechanism is -- has to be -- deeply embedded within the Perl core; and the historic convention that says Perl does not break backward compatibility; and the net result is that you will have to learn to live with what is; because it is very unlikely to change at this point in time.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong

        Perl isn't "guessing". It is following the clearly laid out rule for 'detainting'. That is: "Perl presumes that if you reference a substring using $1, $2, etc., that you knew what you were doing when you wrote the pattern."

        The problem with this is that the "clearly laid out rule for 'detainting'" is too ambiguous. In perl, Regexp matches are used to do a lot of different things, and removing malicious characters is only one of them. So for perl to assume that a variable derived from a tainted variable through a regexp match is "clean" is dangerous.

        See what I wrote here: http://www.perlmonks.org/?node_id=1002125

        You can try putting forwards your arguments for a different -- presumably better in your eyes -- way of working; but given how long the current mechanism has been in place; that the mechanism is -- has to be -- deeply embedded within the Perl core; and the historic convention that says Perl does not break backward compatibility; and the net result is that you will have to learn to live with what is; because it is very unlikely to change at this point in time.

        Forgot to reply to that bit. I already outlined what I (probably arrogantly) believe would be a better solution in the middle of this page:

        http://www.perlmonks.org/?node_id=1002107

        But sadly, I think you are probably right that we are stuck with the current taint mode implementation. I'm just surprised that it wasn't done that way in the first place.

      ... [let] me tell it when I think I have looked at it closely enough (for example, [by] invoking a method untainted() on a variable) ...

      But how would you "look at it" in the first place? Almost always by a regex match of some kind. So one would wind up with a statement like
          untaint($hinky) if my @safe = $hinky =~ m{ \A now (get) some (stuff) here \z }xms;
          then_do_safe_stuff_with($hinky, @safe);  # $hinky now safe, too

      But what is to be gained by making explicitly required an action that is already implicit in the successful regex match? Everything still depends on crafting an effective validation regex.

        But what is to be gained by making explicitly required an action that is already implicit in the successful regex match? Everything still depends on crafting an effective validation regex.

        The problem is that regexp matches are typically used to do a lot of different things, and removing malicious characters is only one of them. So assuming that a variable derived from a tainted variable through a regexp match is "clean" is dangerous.

        For example, I have a fairly large code base that I wrote before I became concerned about security issues. In this code base, there are plenty of places where I capture regexp groups on user inputs for reasons that have nothing to do whatsover with removing malicious characters. For example, there are many places where I use regexps to strip out the leading and trailing characters of a user input. As a result, all those strings will be considered kosher by taint mode. In contrast, if taint mode forced me to explicitly label a variable as being untainted, those cases would be correctly identified as being currently tainted.

        I'm not clutching at straws here. This is a real situation, and I am sure there are plenty of folks who have examples of this problem in their code (and I bet this includes a lot of folks who run taint mode).

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1002011]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (9)
As of 2014-07-30 02:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (229 votes), past polls