segfault in 2.11 when using url= about yubico-pam

[Mrten]

valgrind of non-stripped ykclient lib:

rten@tahoe:~$ valgrind --leak-check=full su
==16730== Memcheck, a memory error detector
==16730== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==16730== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==16730== Command: su
==16730==
Yubikey for `root':
==16730== Invalid read of size 1
==16730==    at 0x528F3B1: vfprintf (vfprintf.c:1630)
==16730==    by 0x534CD8F: __vsnprintf_chk (vsnprintf_chk.c:65)
==16730==    by 0x534CCD7: __snprintf_chk (snprintf_chk.c:36)
==16730==    by 0x6C730BE: ykclient_expand_urls (stdio2.h:65)
==16730==    by 0x6C743C1: ykclient_request_process (ykclient.c:1295)
==16730==    by 0x6C744F1: ykclient_request (ykclient.c:1336)
==16730==    by 0x6A6BD14: pam_sm_authenticate (in /lib/security/pam_yubico.so)
==16730==    by 0x4E34B44: ??? (in /lib/x86_64-linux-gnu/libpam.so.0.83.0)
==16730==    by 0x4E343C7: pam_authenticate (in /lib/x86_64-linux-gnu/libpam.so.0.83.0)
==16730==    by 0x4028FD: ??? (in /bin/su)
==16730==    by 0x526576C: (below main) (libc-start.c:226)
==16730==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==16730==
==16730==
==16730== Process terminating with default action of signal 11 (SIGSEGV)
==16730==  Access not within mapped region at address 0x1
==16730==    at 0x528F3B1: vfprintf (vfprintf.c:1630)
==16730==    by 0x534CD8F: __vsnprintf_chk (vsnprintf_chk.c:65)
==16730==    by 0x534CCD7: __snprintf_chk (snprintf_chk.c:36)
==16730==    by 0x6C730BE: ykclient_expand_urls (stdio2.h:65)
==16730==    by 0x6C743C1: ykclient_request_process (ykclient.c:1295)
==16730==    by 0x6C744F1: ykclient_request (ykclient.c:1336)
==16730==    by 0x6A6BD14: pam_sm_authenticate (in /lib/security/pam_yubico.so)
==16730==    by 0x4E34B44: ??? (in /lib/x86_64-linux-gnu/libpam.so.0.83.0)
==16730==    by 0x4E343C7: pam_authenticate (in /lib/x86_64-linux-gnu/libpam.so.0.83.0)
==16730==    by 0x4028FD: ??? (in /bin/su)
==16730==    by 0x526576C: (below main) (libc-start.c:226)
==16730==  If you believe this happened as a result of a stack
==16730==  overflow in your program's main thread (unlikely but
==16730==  possible), you can try to increase the size of the
==16730==  main thread stack using the --main-stacksize= flag.
==16730==  The main thread stack size used in this run was 8388608.
==16730==
==16730== HEAP SUMMARY:
==16730==     in use at exit: 209,346 bytes in 2,301 blocks
==16730==   total heap usage: 3,057 allocs, 756 frees, 288,622 bytes allocated
==16730==
==16730== 48 bytes in 1 blocks are definitely lost in loss record 58 of 126
==16730==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16730==    by 0x405CA2: ??? (in /bin/su)
==16730==    by 0x4050CF: ??? (in /bin/su)
==16730==    by 0x402847: ??? (in /bin/su)
==16730==    by 0x526576C: (below main) (libc-start.c:226)
==16730==
==16730== 101 (48 direct, 53 indirect) bytes in 1 blocks are definitely lost in loss record 71 of 126
==16730==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16730==    by 0x405CA2: ??? (in /bin/su)
==16730==    by 0x4050CF: ??? (in /bin/su)
==16730==    by 0x404417: ??? (in /bin/su)
==16730==    by 0x4024EA: ??? (in /bin/su)
==16730==    by 0x526576C: (below main) (libc-start.c:226)
==16730==
==16730== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 89 of 126
==16730==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16730==    by 0x53495A4: nss_parse_service_list (nsswitch.c:678)
==16730==    by 0x534A065: __nss_database_lookup (nsswitch.c:175)
==16730==    by 0x5E0F2A4: ???
==16730==    by 0x53029BC: getpwnam_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
==16730==    by 0x5302383: getpwnam (getXXbyYY.c:117)
==16730==    by 0x4026DF: ??? (in /bin/su)
==16730==    by 0x526576C: (below main) (libc-start.c:226)
==16730==
==16730== LEAK SUMMARY:
==16730==    definitely lost: 156 bytes in 3 blocks
==16730==    indirectly lost: 293 bytes in 15 blocks
==16730==      possibly lost: 0 bytes in 0 blocks
==16730==    still reachable: 208,897 bytes in 2,283 blocks
==16730==         suppressed: 0 bytes in 0 blocks
==16730== Reachable blocks (those to which a pointer was found) are not shown.
==16730== To see them, rerun with: --leak-check=full --show-reachable=yes
==16730==
==16730== For counts of detected and suppressed errors, rerun with: -v
==16730== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 2)

[Mrten]

and this leads me to:
url=http://yubikey/wsapi/2.0/verify?id=%s&otp=%s
which should be
url=http://yubikey/wsapi/2.0/verify?id=%d&otp=%s

Can't you catch this?

[klali]

Yes.. But it will go hand-in-hand with changing yubico-c-client and probably adding a new API with saner format strings.

/klas

[Mrten]

Agree, it's not like the %d and %s are optional as they are used at the moment.

[klali]

since yubico-c-client version 2.12 there's a new api call ykclient_set_url_bases() that can be used with a simple url (http://yubikey/wsapi/2.0/verify) maybe we should create a new option that uses that and allows setting several urls as well. (in reference to #21)

[klali]

now there's a new option called urllist (only on master yet), with that going out I think we should discourage use of the url option..
If it's possible for you to test the current code on master and see if you think the urllist option makes senes that'd be great..

/klas