Created attachment 1357681 [details] fix array bounds violation Description of problem: The pkcs11-helper package contains a patch (pkcs11-helper-rfc7512.patch) that makes it understand RFC 7512 PKCS#11 URIs. Unfortunately, at least when using Aventra MyEID tokens, this fails due to an array bounds violation. Version-Release number of selected component (if applicable): pkcs11-helper-1.22-3.fc27 How reproducible: Try to establish connection with OpenVPN, and giving a RFC 7512 URI as "pkcs11-id" parameter. Steps to Reproduce: 1. openvpn --remote myvpn.host 1194 --dev tun --comp-lzo --client --auth SHA384 --cipher AES-256-CBC --ca ~/.cert/ca.crt --remote-cert-tls server --pkcs11-providers /usr/lib64/pkcs11/opensc-pkcs11.so --pkcs11-id 'pkcs11:model=PKCS%2315;token=User%20PIN%20%28MyEID%29;manufacturer=Aventra%20Ltd.;serial=3129034798967503;id=%e9%15%28%2a%ab.VD%d2%a6B%ca%e2%e8%fe%96%9bd0%81' Actual results: Wed Nov 22 12:28:29 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017 Wed Nov 22 12:28:29 2017 library versions: OpenSSL 1.1.0g-fips 2 Nov 2017, LZO 2.08 Wed Nov 22 12:28:29 2017 PKCS#11: Adding PKCS#11 provider '/usr/lib64/pkcs11/opensc-pkcs11.so' Wed Nov 22 12:28:32 2017 PKCS#11: Cannot deserialize id 19-'CKR_ATTRIBUTE_VALUE_INVALID' Expected results: I would expect openvpn to enter a livelock when asking for the token PIN due to the fork handler problem when compiled with systemd support (which is another problem, but not relevant here). Additional info: The reason for the problem is an array bounds violation. This occurs, for example, when the serial number of the token has the maximal permitted length of 16 characters (as in the example above). After processing the last character, the function __parse_token_uri_attr increments the pointer tokstr, which then points to the last (i.e. seventeenth) character of serialNumber, and afterwards writes a 0-byte to tokstr[1], which incidentally is the first byte of the following field, "label", thereby erasing the previously-parsed token label. I would suggest to apply the attached patch on top of pkcs11-helper-rfc7512.patch to avoid this problem.
Thank you for the report and the patch. It seems reasonable, and I also think that access to tokstr[1] seem incorrect. David do you have any concern to raise before I apply the patch? I guess that this should be reflect also at: https://github.com/OpenSC/pkcs11-helper/pull/4
Looks sane to me, although I haven't tested it here. I've update the pull request accordingly. Thanks.
pkcs11-helper-1.22-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c9b314a20d
pkcs11-helper-1.22-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-31118b9e89
pkcs11-helper-1.22-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
pkcs11-helper-1.22-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.