> From: owner-openssl-...@openssl.org On Behalf Of John Reed via RT > Sent: Wednesday, 28 January, 2009 12:42
> When using AES_cbc_encrypt, if an IV passed to the function has an > incorrect length, a segmentation fault will occur. Attached is the s/will/may/; or a wide variety of other bad things may happen, including data corruption with no reported/signalled error. But only if it's too short; if it's too long that's OK. And similarly for your data buffers and in fact all buffers. > testlog and a dump file. The IV pointer is the memory location passed to > the encryption function, this is where the fault occurs. Obviously, > implementations can easily perform error checking before passing the IV > to the encryption function, but a segmentation fault is a bit extreme if > an implementation does not perform error checking, and ultimately > killing whatever application that they have running. > That's C for you. C arrays don't maintain their own length. Even if the API forced you to pass a length, at significant inconvenience to all the other C programmers who already put in the (often nontrivial) effort to get it right, nothing could stop you from passing the wrong length and causing the same problem. This is the same reason Microsoft's 'safer C library' is misguided; C just wasn't designed for this kind of safety, and slathering on lipstick doesn't change that. > In my implementation, I am using Python and a wrapper to the OpenSSL > library. You can see this in the backtrace. If you need more information > please feel free to contact me. > Adding this kind of safety check (and others) in wrapper for a language designed for safety, like Python, or Ada, or perl, makes excellent sense. If yours doesn't, you might look into adding it. (Or Java, but that already has its own crypto and SSL.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
