Opened 12 years ago

Last modified 20 months ago

#226 new Bug / Defect

'--auth-user-pass-verify <script> VIA-FILE' can not pass long passwords (>~512)

Reported by: ye_olde_iron Owned by:
Priority: minor Milestone: release 2.6
Component: Generic / unclassified Version: OpenVPN 2.2.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


While misc.h defines a maximum password length of 4096 when ENABLE_PKCS11 is defined ( ... # define USER_PASS_LEN 4096 ...) you can not successfully write a long password to a file via '--auth-user-pass-verify' as there is a buffer size limit of 512 bytes in status.c/status_printf() (STATUS_PRINTF_MAXLEN is defined as 512 just above the status_printf() routine).

[If output is to a file ssl.c/verify_user_pass_script() executes 'status_printf (so, "%s", up->password);']

It would be sensible to increase the buffer size in status.c/status_printf() so that the max length for passwords is consistent.

At the present time the only way to pass a longer password is via the environment variables (I.E. '--auth-user-pass-verify <script> VIA-ENV') ... not the best option as this is documented as being 'is insecure on some platforms' :-(

Change History (5)

comment:1 Changed 12 years ago by ye_olde_iron

Potential solution ... in status.c :-

(a) include misc.c so that we can get the definition of USER_PASS_LEN.

(b) change the definition of STATUS_PRINTF_MAXLEN to use USER_PASS_LEN+2 as long as it is defined and greater than, or equal to, 512 (otherwise just define it as 512 as before).

--- status.c_ORIG	2011-11-25 10:32:21.000000000 +1300
+++ status.c	2012-08-20 13:13:45.000000000 +1200
@@ -29,6 +29,9 @@
 #include "memdbg.h"
+/* misc.h so that we can get USER_PASS_LEN */
+#include "misc.h"
  * printf-style interface for outputting status info
@@ -214,7 +217,15 @@
   return ret;
+#  if USER_PASS_LEN < 512
+#    define STATUS_PRINTF_MAXLEN 512
+#  else
+#  endif
 status_printf (struct status_output *so, const char *format, ...)

comment:2 Changed 11 years ago by Samuli Seppänen

Priority: majorminor

comment:3 Changed 10 years ago by Gert Döring

I'm wondering a bit where this 4096 byte length is coming from. Is this something a pkcs#11 device might spit out as a *password*? Because for normal passwords, 512 byte should be truly long enough.

comment:4 Changed 10 years ago by bdlow

There are other authentication mechanisms that have something other than a user password in the password field, for example a signed token.

In any event, the limit should be consistent between USER_PASS_LEN, via-file, via-env.

comment:5 Changed 20 months ago by Gert Döring

Milestone: release 2.6

I see this USER_PASS_LEN <-> PKCS11 issue show up every now and then, so it seems we might want to clean this up for good, one day.

Maybe not doable for 2.6.0, but still bumping the milestone so this get some visibility.

Note: See TracTickets for help on using tickets.