Re: x509 parsing bug + fuzzing crypto in the userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 23, 2017 at 10:35 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> On Thu, Nov 23, 2017 at 10:32 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>> On Wed, Nov 22, 2017 at 6:08 PM, Stephan Mueller <smueller@xxxxxxxxxx> wrote:
>>> Am Mittwoch, 22. November 2017, 11:44:51 CET schrieb Dmitry Vyukov:
>>>
>>> Hi Dmitry,
>>>
>>>>
>>>> Thanks! I think we can incorporate this into syzkaller.
>>>>
>>>> One question: what's the relation between alg names and type ("aead",
>>>> "hash", "rng", "skcipher")?
>>>
>>> If you refer to AF_ALG, then the following applies:
>>>
>>> AF_ALG type of aead -> kernel crypto API: crypto_aead_*, aead_request_*
>>>
>>> AF_ALG type of skcipher -> kernel crypto API: crypto_skcipher_*,
>>> skcipher_request_*
>>>
>>> AF_ALG type of hash -> kernel crypto API: crypto_ahash_*, ahash_request_*
>>>
>>> AF_ALG type of rng -> kernel crypto API: crypto_rng_*
>>>
>>>
>>>> I remember I already looked at it before
>>>> and could not figure it out. Are all algorithms and templates
>>>> partitioned between types? Or they are orthogonal?
>>>
>>> If you refer to the cipher names, there are two types: templates and cipher
>>> implementations. See [1] for details. [2] gives you some ideas of the
>>> interrelationships between the templates and the ciphers.
>>>
>>> The relationship between the names and the AF_ALG names mentioned above is
>>> defined with the .cra_flags in the cipher specification of each cipher
>>> implementation. See [3] for details.
>>>
>>> Note, I started some fuzzing work in my libkcapi test application. See [4] for
>>> the implementation.
>>>
>>> [1] http://www.chronox.de/crypto-API/crypto/architecture.html#crypto-api-cipher-references-and-priority
>>>
>>> [2] http://www.chronox.de/crypto-API/crypto/architecture.html#internal-structure-of-kernel-crypto-api
>>>
>>> [3] http://www.chronox.de/crypto-API/crypto/architecture.html#cipher-allocation-type-and-masks
>>>
>>> [4] https://github.com/smuellerDD/libkcapi/blob/master/test/kcapi-main.c line
>>> 522
>>
>>
>> I've read the links and starring at the code, but still can't get it.
>> The question is about textual type names in sockaddr.
>> .cra_flags does not specify textual names.
>> [3] again talks about int flags rather than textual names.
>>
>> I see they are used here:
>> http://www.chronox.de/crypto-API/crypto/userspace-if.html#aead-cipher-api
>>
>> but it merely says:
>>
>>     .salg_type = "aead", /* this selects the symmetric cipher */
>>     .salg_name = "gcm(aes)" /* this is the cipher name */
>>
>> and does not explain why it is must be "aead" for  "gcm(aes)", nor why
>> would "skcipher" fail for  "gcm(aes)" (would it?).
>>
>> These integer flags in sockaddr_alg.feat/mask seem to be better always
>> be 0 (because they can only fail an otherwise passing bind, right?).
>> But the textual type seems to matter, because bind first looks at type
>> and then everything else happens as callbacks on type.
>>
>> I've found these guys:
>>
>> tatic const struct crypto_type crypto_skcipher_type2 = {
>> .extsize = crypto_skcipher_extsize,
>> .init_tfm = crypto_skcipher_init_tfm,
>> .free = crypto_skcipher_free_instance,
>> #ifdef CONFIG_PROC_FS
>> .show = crypto_skcipher_show,
>> #endif
>> .report = crypto_skcipher_report,
>> .maskclear = ~CRYPTO_ALG_TYPE_MASK,
>> .maskset = CRYPTO_ALG_TYPE_BLKCIPHER_MASK,
>> .type = CRYPTO_ALG_TYPE_SKCIPHER,
>> .tfmsize = offsetof(struct crypto_skcipher, base),
>> };
>>
>> But it still does not make sense to me.
>>  CRYPTO_ALG_TYPE_SKCIPHER const is not mentioned in any actual algorithms.
>> and CRYPTO_ALG_TYPE_BLKCIPHER_MASK is 0xc, which selects
>> CRYPTO_ALG_TYPE_BLKCIPHER, CRYPTO_ALG_TYPE_KPP and
>> CRYPTO_ALG_TYPE_RNG. And it looks like a random subset of
>> constants....
>
>
> Also, there seems to be only 4 types ("aead", "hash", "rng",
> "skcipher"), but more algorithm types. For example, how do I get
> access to ACOMPRESS/SCOMPRESS?

Looking at /proc/crypto confuses me even more:

$ cat /proc/crypto  | grep type | sort | uniq
type         : ablkcipher
type         : aead
type         : ahash
type         : akcipher
type         : blkcipher
type         : cipher
type         : compression
type         : givcipher
type         : rng
type         : shash

Now, there are 10 types. They partially intersect with the other
textual types (e.g. "aead"). But, say "skcipher" is not present in
/proc/crypto at all.



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux