On 11/19/2013 8:48 PM, Костырев Александр Алексеевич wrote:

Good day to all!

We would like to authenticate our ejabberd against Dovecot with perl

there's such a script http://www.ejabberd.im/files/contributions/check_dovecot.pl.txt

that script uses following perl library - http://cpansearch.perl.org/src/SASHA/Authen-SASL-Authd-0.04/lib/Authen/SASL/...

Authentication is OK, but sub user_dovecot wich queues information about a specific user doesn't work with error

dovecot: auth: Error: BUG: Authentication client sent unknown handshake command: USER?1?user60@atlas-2.ru

could someone help with this ?

thanks in advance!

I started to look through the script to find the problem, however, it quickly became obvious that whoever wrote it knew very little about programming Perl or security.

Do not use this script. It is only one page long and yet contains so many problems, bugs and security holes, that it would take much more than that to describe. It is easier just to write it correctly from scratch.

• First, it does not have the warning flag turned on, which would have caught a lot of problems.

• Second, it is used for data coming in over the Internet, and yet it does not run in taint mode. This allows a lot of programming mistakes to slip by and hackers can exploit this fact.

• Third, the section that supposedly filters dangerous characters, does not. Best security practice says that you allow a safe set of characters and discard the rest, *not* the other way around (discarding just the "dangerous" characters, keeping the rest). What if the localized character set has a quote character that the shell recognizes, but is not in your list of banned characters?

Also, it is much easier to comprehend and visualize a list of characters that are allowed, versus trying to figure out which ones aren't by elimination. Do you have the entire set of localized characters memorized and can you mentally figure which of them are left after removing a specific few? What happens in a different localization?

• Fourth, clearly the author of this knows C, but does not know Perl. Perl has no switch statement. The simulated switch statement in this script is just a named block with a series of commands that have gotos escaping the block (the last statement). This is confusing and hides sneaky bugs.

For instance, each command is really of the form: $op eq 'xyz' and do { ... }, last SWITCH;

This is a compound statement, which often has hidden, unintended side effects.

How will this be evaluated; in scalar context or list context? What are the side effects of each? What is the operator precedence of the "and" compared to the comma operator at the end? Why should you even need to worry about such things? They just lead to hard-to-find programming bugs.

This statement hides an "if" statement as a fake switch statement. Just use a real if / elsif / elsif / else construct. Perl knows how to optimize such things and a genuine if / elsif cascade will execute faster than this simulated switch statement and be less confusing to understand.

• Fifth, the variable "$result" is set to the barewords "true" or "false".

1. Barewords are bad and would have generated errors if the warnings flag was on, which it should have been.
2. In Perl, these are not keywords. As such, they are treated as normal strings, so in both cases you are setting the variable to a string of either "true" or false", both of which are true when evaluated in boolean context. At the end, when setting the $out variable, YOU ALWAYS RETURN TRUE!!! regardless of whether the user authenticated correctly or not.

This just scratches the surface and there are a lot more problems: cuddled elses, not checking return values, not trapping errors, using negative conditionals, confusing and ambiguous use of the ternary operator, etc.

Do not use this script. That is, unless you are setting up a hacking contest and inviting people to hack your system, in which case, go right ahead.

For more information, get a copy of the book "Perl Best Practices".

Cheers.

Dem