Need help in understanding the role of taint handling in Dancer
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
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@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
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@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@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
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@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@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@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
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@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@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@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@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (2)
-
Flavio Poletti -
Gurunandan Bhat