[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