Re: x509 parsing bug + fuzzing crypto in the userspace

[Stephan Mueller <smueller@chronox.de>]

Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov:

Hi Dmitry,

> I've cooked syzkaller change that teaches it to generate more
> algorithm names. Probably not idea, but much better than was before:
> https://github.com/google/syzkaller/blob/ddf7b3e0655cf6dfeacfe509e477c1486d2
> cc7db/sys/linux/alg.go

I am not as fluent in GO, so I may miss a point here:

		{"authencesn", []int{ALG_HASH, ALG_BLKCIPHER}},
		{"authenc", []int{ALG_HASH, ALG_BLKCIPHER}},

These both are templates to form an AEAD cipher. They allow you to specify the 
block cipher and the hash type.


		{"rfc7539esp", []int{ALG_BLKCIPHER, ALG_HASH}},
		{"rfc7539", []int{ALG_BLKCIPHER, ALG_HASH}},
		{"rfc4543", []int{ALG_AEAD}},
		{"rfc4106", []int{ALG_AEAD}},

These are no ciphers per se, but simply formatting mechanisms. For example, to 
make use of rfc4106, you must split the IV: the first four bytes need to be 
appended to the key and the trailing 8 bytes are used as the IV. Any other 
formatting should cause an error. Besides, these implementations should only 
work with some AEAD ciphers like GCM.


		{"pcrypt", []int{ALG_AEAD}},
		{"rfc4309", []int{ALG_AEAD}},
		{"gcm", []int{ALG_CIPHER}},
		{"gcm_base", []int{ALG_BLKCIPHER, ALG_HASH}},
		{"ccm", []int{ALG_CIPHER}},
		{"ccm_base", []int{ALG_BLKCIPHER, ALG_HASH}},




		{"echainiv", []int{ALG_AEAD}},
{"seqiv", []int{ALG_AEAD}},

These are IV generators and should be used with an AEAD cipher to internally 
generate IVs. Note, the use of IV generators have changed with 4.2 (see my 
script I sent you as part of this thread).



		{"gcm(aes)", nil},

gcm() is also a template that can consume any block cipher, including aes-
generic, serpent, ...

		{"gcm_base(ctr(aes-aesni),ghash-generic)", nil},

Again, ctr() is a template that can consume other block ciphers.

		{"generic-gcm-aesni", nil},

Does this exist?

		{"rfc4106(gcm(aes))", nil},

rfc... is a template that can consume AEAD ciphers.

		{"rfc4106-gcm-aesni", nil},
		{"__gcm-aes-aesni", nil},
{"__driver-gcm-aes-aesni", nil},

Please specifically test that __driver_... names should NEVER be allocatable 
from user space.



	// algorithms:
		{"cbc(aes)", nil},

cbc() is a template


		{"cbc(aes-aesni)", nil},
		{"chacha20", nil},
		{"chacha20-simd", nil},
		{"pcbc(aes)", nil},
		{"pcbc-aes-aesni", nil},
		{"fpu(pcbc(__aes))", nil},
		{"fpu(pcbc(__aes-aesni))", nil},
		{"pcbc(__aes)", nil},
		{"pcbc(__aes-aesni)", nil},

They are all templates.

		{"xts(aes)", nil},

xts() is a template.

Note, starting with 4.9, you must use xts(ecb(aes)).

		{"xts-aes-aesni", nil},
{"ctr(aes)", nil},

ctr() is a template



In general, I would rather suggest:

1. identify all templates and mark them what they can consume (other 
templates, AEAD, skcipher, hash, ...)

2. identify all ciphers (aes, aes-generic, aes-aesni, ...) and identify their 
types (skcipher, hash)

3. mix-n-match templates with the ciphers according to what templates can 
consume


Start another test where you arbitrarily mix-n-match templates and ciphers or 
even bogus names, NULL, etc.


One word of warning: some cipher names may look like templates, but they are 
not: gcm(aes) in arch/x86/crypto/ is a complete cipher and not consisting of 
templates. Thus, I would always use the driver names (gcm-aes-aesni for the 
given example) to ensure you test exactly the cipher you had in mind.

Word of warning II: There is a bug in the kernel crypto API: if you allocate a 
cipher using the driver name that was not registered before, this cipher will 
never be available using its "name". /proc/crypto shows you the reason: the 
"name" is then identical to the driver name.

Ciao
Stephan