Fwd: LP#929108 support reading PIN from file when using PKCS#11 devices
stefw at gnome.org
Mon Apr 16 10:27:06 PDT 2012
On 2012-04-16 18:50, Nikos Mavrogiannopoulos wrote:
> 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.
Is the problem of PKCS#11 URIs from untrusted sources sufficiently
understood? Until the problem and use cases are better understood, I
would err on the side of discouraging any use of PKCS#11 URIs from
>> 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
1MB be a good max sanity check size?
Also, while we're on the topic, is the current behavior of reading the
PIN file byte-for-byte verbatim what's generally expected?
More information about the p11-glue