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/Authd.pm
>
> 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 at 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