During SecurePass compatibility tests, we discovered that ProFTPD RADIUS module authentication was not working, but was working fine with the LDAP module.

Problem details

From SecurePass side, we were seeing spurious characters being added to the real password. I had to modify a radius analyzer to be able to understand where the problem was.
I was able to understand the problem after hours working on it: it seems that the memory buffer from ProFTPD radius module is somehow “tainted”. The resulting string has the password null terminated, but the rest of the buffer was not “cleared” with nulls and had some other characters instead. Just as an example, here’s what the module was sending on the wire:

intead of:

Most of RADIUS libraries are written in C and a string is terminated usually with a null: in both cases the result is a “test” password.
In other languages, this is not true therefore SecurePass was receiving “testtestAKD” instead.

Resolution

To resolve this problem you can:

  1. use ProFTPD PAM authentication and use pam_radius
  2. use ProFTPD LDAP authentication (this requires a  SecurePass Premier account)
  3. we developed a SecurePass module that allows to run into a chroot enviroment to have a more secure environment. If you are interested in this solution, please contact one of the SecurePass’ advisor

Further reading

2012-06-17