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

[Stef Walter]

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?

Cheers,

Stef