[erlang-bugs] Problems in crypto_drv.c

Christopher Stawarz cstawarz@REDACTED
Thu Aug 30 21:56:30 CEST 2007


I've noticed some issues with the implementation of
crypto:rand_bytes() and the crypto driver in general.  Here are lines
357-358 of otp_src_R11B-5/lib/crypto/c_src/crypto_drv.c:

	*rbuf = (char *)(bin = driver_alloc_binary(rlen));
	RAND_pseudo_bytes(bin->orig_bytes,rlen);

I see the following problems here:

1) The random bytes are generated with RAND_pseudo_bytes(), which
    (unlike RAND_bytes()) isn't guaranteed to produce a
    cryptographically-strong result.  Perhaps the crypto module should
    export both rand_bytes() and rand_pseudo_bytes(), so the user can
    choose?

2) RAND_pseudo_bytes() can fail (returning -1), but the driver won't
    detect this because it doesn't check the return value.

3) Most seriously, driver_alloc_binary() can return NULL (presumably
    if malloc() fails), but the code doesn't check for this and blindly
    dereferences the returned pointer in the next line.  Since this is
    a linked-in driver, a NULL return will lead immediately to the
    entire VM crashing.

Problem (3) (neglecting to check for allocation failures) appears
repeatedly throughout crypto_drv.c.  While I admit that equating
malloc() failure with certain death isn't too unreasonable in many
situations, it seems unacceptable in a system reputedly able to
provide "9 nines reliability".  I'd be interested in hearing
explanations/opinions to the contrary.


Thanks,
Chris Stawarz



More information about the erlang-bugs mailing list