On Thu, Dec 22, 2011, Per Hedeland wrote:
> Hello,
>
> I recently had the misfortune of running into the case of an application
> built with an OpenSSL installation that had the RC4_CHAR option set
> (linux-ppc in Configure), but run using libcrypto.so from an
> installation that *didn't* have RC4_CHAR set (Debian/powerpc). As could
> be expected, every call to RC4_set_key() would overwrite some 770 random
> bytes of memory.
>
> I thought it would be nice if the app could detect this problem and
> abort with an error message instead of crashing, and came up with this:
>
> const char* RC4_opt = RC4_options();
>
> if (sizeof(RC4_INT) == 1) {
> if (find_opt(RC4_opt, "int") != NULL) {
> error("RC4_CHAR");
> }
> } else {
> if (find_opt(RC4_opt, "char") != NULL) {
> error("RC4_CHAR");
> }
> }
>
> A bit of a hack I guess, but it worked great until it was tested on a
> x86_64 system that used the asm code, where the string returned by
> RC4_options() doesn't actually report the type of RC4_INT. (Actually the
> string *varied*, with about a 25-25-50 distribution between the three
> possible values, but that's another story.)
>
> So... Am I going about this completely wrong, and there is some nice
> clean way to figure out how the library was built? Or second best, is it
> possible to assume something about the type of RC4_INT based on the fact
> that the asm code is used? I realize that RC4_options() is undocumented
> and thus can be changed without notice etc, plus of course that any
> distributor can modify the code anyway - I'll take my chances and am
> only wondering about the current (and maybe semi-recent past) code as
> released by the project.
>
> I'm also interested in a similar test for DES_INT - I haven't come
> across any problems using a scheme like the above with DES_options(),
> but if there is a cleaner way I would like to know about it. Also, if
> there are other config options that are known to break binary
> compatibility I would be interested in info about those too.
>
> I have noted the "Applications should use the higher level functions
> EVP_EncryptInit(3) etc. instead of calling the RC4 functions directly.",
> but unfortunately this isn't an option for "historical reasons". And I
> have tried to search the OpenSSL documentation and FAQ as well as
> Google, but without success.
>
Well whatever you do here is likely to be a a hack which could well break in
future etc etc etc...
With that disclaimer out of the way you *might* be able to make use of the
EVP_CIPHER structures here. Take a look at crypto/evp/e_rc4.c and you'll see
the ctx_size field is set to sizeof(EVP_RC4_KEY).
So one possibility is to compare this value to the expected value. You can do
similar things with DES.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
