Fwd: LP#929108 support reading PIN from file when using PKCS#11 devices
nmav at gnutls.org
Mon Apr 16 09:50:36 PDT 2012
On 04/16/2012 06:42 PM, Stef Walter wrote:
> * An application uses a URI which it received from an untrusted
> * The URI contains a pin-source which nobody in the stack has
> registered to handle (and thus the gnutls installed fallback file
> handler is used).
> * And the application wasn't expecting the PKCS#11 URI to read from a
> file and use it as a PIN.
> * And somehow this gives an attacker an advantage they would not
> otherwise have.
> I think that's a pretty remote possibility, and if an attacker can
> specify a PKCS#11 URI at all, then they are able to control which keys
> and certs are used. In that case it seems that being able to specify a
> PIN read from a file is irrelevant. PKCS#11 URIs should not come from
> untrusted sources.
Maybe this can be mitigated by providing a sanitize_pkcs11_url()
function that would strip this field? Then programmers would be advised
to call this function for untrusted urls.
> But for sanity's sake would we want to limit the size of the file that
> p11-kit will read in its p11_kit_pin_file_callback() handler?
Having a sanity check would also be good regardless of a url sanitize
>> I've currently added the check, but if the file callback fails
>> I should remove it.
> Now that I think about it, I don't think the attempts check is correct.
> It assumes that the PIN returned from a registered pin-source handler
> will always be identical on each try. That's the case for the
> p11_kit_pin_file_callback() but not the case for pretty much any other
> handler (such as prompts and such).
I've removed it. p11_kit_pin_file_callback() properly handles the
More information about the p11-glue