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

[Nikos Mavrogiannopoulos]

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.

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

>> 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
P11_KIT_PIN_FLAGS_RETRY flag.

regards,
Nikos