|
|
| Author |
Message |
|
| Guest |
 Posted: Thu Aug 30, 2007 7:58 pm |
 |
|
|
Guest
|
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
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
