Fwd: LP#929108 support reading PIN from file when using PKCS#11 devices

Stef Walter stefw at gnome.org
Mon Apr 16 19:27:06 CEST 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
>>    source.
>>  * 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.
> Interesting.
>> 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
untrusted sources.

>> 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
> function.

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 Gnutls-devel mailing list