[Dancer-users] Need help in understanding the role of taint handling in Dancer

[Gurunandan Bhat]

Yes - would be great to do that.
To keep things focussed on the issue at hand, let me strip all the PKI stuff
and post it here.
Will take me a day....

Thank you.


On Wed, Apr 20, 2011 at 2:41 PM, Flavio Poletti <polettix at gmail.com> wrote:

> Would you produce a minimal test script that exposes the problem?
>
> Cheers,
>
>     Flavio.
>
>
> On Wed, Apr 20, 2011 at 9:41 PM, Gurunandan Bhat <gbhat at pobox.com> wrote:
>
>> Thanks Flavio.
>>
>>
>>    1. The input string for encryption is byte-level identical in both
>>    cases. I have used unpack to look at the input string in both cases to
>>    confirm this. I have run a large number of tests.
>>     2. I have used the regular expression trick to untaint (just in case)
>>    in my own code. In addition, I am using Data::FormValidator to validate the
>>    input strings so I guess it uses a regexp check in any case. For good
>>    measure I have passed the option untaint_all_constraints => 1 to DFV just in
>>    case.
>>    3. There is something in the Dancer runtime environment that makes
>>    Crypt::OpenSSL::RSA do the wrong thing. If it is not taint and it is not
>>    encoding (which I have confirmed) - what could it be? If I knew this I could
>>    pass it on to the Crypt::OpenSSL::RSA guys so that they can fix whatever it
>>    is thats going wrong there.
>>
>>
>> Thanks once again for your time and your attention
>>
>>
>>
>>
>> On Wed, Apr 20, 2011 at 12:18 PM, Flavio Poletti <polettix at gmail.com>wrote:
>>
>>> I would be surprised if taint is the cause of your pain. From what I
>>> know:
>>>
>>> * you are the sole responsible for activating taint mode. It has to be
>>> set in the hash-bang and possibly provided on the command line;
>>> * when taint kicks in something like "die()" happens, so you should be
>>> pretty aware of it (unless you wrap it all with eval() and throw away any
>>> error).
>>>
>>> You can try your command-line script with taint mode turned on by means
>>> of the "-T" command-line switch (see perldoc perlrun for details). If you
>>> want to try and untaint the input string for the password, you have to use a
>>> regular expression:
>>>
>>> my ($untainted_password) = $tainted_password =~ /(.*)/;
>>>
>>> Note that the "blind untaint" method above is frowned upon, tainting is
>>> all about forcing you (the programmer) to carefully check your inputs so you
>>> should try to figure out the correct way to validate the input. In this case
>>> I think that we can assume that any character is valid for a password, so
>>> the whole string is good.
>>>
>>>
>>> One thing I'd look at is encoding. I'd try to see whether, in the two
>>> different contexts, the two password:
>>>
>>> 1. have the same encoding status (use utf8::is_utf8() for this, see
>>> perldoc utf8)
>>> 2. are exactly the same (in this case I'd use something like
>>>
>>>    warning unpack 'H*', $password;
>>>
>>> in order to see the raw bytes in hex).
>>>
>>> Good luck,
>>>
>>>     Flavio.
>>>
>>>
>>>
>>> On Wed, Apr 20, 2011 at 8:20 PM, Gurunandan Bhat <gbhat at pobox.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I am in the process of writing a Dancer application that does (in part)
>>>> some heavy lifting of PKI (RSA) [en|de]cryption using Crypt::OpenSSL::RSA
>>>> and a few other Crypt::* modules and have been hit with an issue that I do
>>>> not fully understand. Here is a rough sequence of what happens:
>>>>
>>>>
>>>>    1. I have written a Moose based class that does PKI stuff. One of
>>>>    the the methods in this class is encrypting binary strings using a Public
>>>>    Key. The Public Key is read from a file on disk.
>>>>    2. When I run a test script with this class, the encryption works
>>>>    fine.
>>>>    3. When I run the same script as a route handler in Dancer the
>>>>    encryption silently produces the wrong result - decrypting it does not give
>>>>    me the original string.
>>>>    4. Testing is a bit hard and complicated due to the fact that RSA
>>>>    encryption is not deterministic and encrypting the same string twice will
>>>>    give wildly different strings but decrypting both should correctly give the
>>>>    original string. However after a few days of trying out multiple test code -
>>>>    I am reasonably certain that *encryption with Crypt::OpenSSL::RSA
>>>>    gives the correct result from the command line but gives the wrong result
>>>>    when run as a Dance route handler*.I am currently working around
>>>>    this by doing the encryption through a script on disk which the route
>>>>    handler runs - but this is obviously too silly for words.
>>>>
>>>> The only thing I can attribute this to is that my input string collected
>>>> from a form and/or my public key object which I read from file are marked as
>>>> tainted in Dancer but not in a command line script and that
>>>> Crypt::OpenSSL::RSA has a bug when used with tainted variables. This is a
>>>> conjecture but the only one that seems likely given the large amount of
>>>> testing that I have done.
>>>>
>>>> With this background here are a couple of questions that I have:
>>>>
>>>>
>>>>    1. Does Dancer taint input variables received from the user(-form)?
>>>>    2. If yes, how do I untaint it.
>>>>    3. How can I conclusively confirm that taintedness is causing the
>>>>    difference in output between the command line script and the route handler.
>>>>    With identical inputs to my command line script and to my route handler I am
>>>>    certain that there is a difference in output. I am wondering if taintedness
>>>>    is the cause.
>>>>
>>>> Thank you for your patience in reading this rather long message
>>>>
>>>> _______________________________________________
>>>> Dancer-users mailing list
>>>> Dancer-users at perldancer.org
>>>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Dancer-users mailing list
>>> Dancer-users at perldancer.org
>>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110420/a3a06980/attachment-0001.htm>