provider-corner / vigenere Goto Github PK

It looks to me (from code inspection) that vigenere_encrypt_init/vigenere_decrypt_init will happily accept a 0 length key. In the encrypt case it will end up calling memcpy with a final param of 0 (which I think is undefined behaviour). vigenere_update will subsequently result in an out-of-bounds or NULL pointer deref of the zero length key (because it assumes that the key is at least one byte long).

I wrote a rand provider and compiled it into rng.so using fips_rands in fipsprov.c as an example. Then in librnd.so I load and link shared library rng.so using dlopen() and dlsym(). In the binary test_get_rnd_bytes I link librnd.so and run some test cases.

code in librnd.so.

int rng_provider_load(void)
{
...
       handle = dlopen("/lib/rng.so", RTLD_LOCAL | RTLD_NOW);
        if (NULL == handle) {
                ERR_RND("failed to dlopen rng.so(%s)\n", dlerror());
                goto out;
        }   

        provider_init_fn = dlsym(handle, "OSSL_provider_init");
        if (NULL == provider_init_fn) {
                ERR_RND("Failed to load func(%s)\n", dlerror());
                goto out;
        }   

        if (OSSL_PROVIDER_add_builtin(NULL, "rng", provider_init_fn) == 0) {
                ERR_RND("Failed to add rng provider\n");
                goto out;
        }   

        rng_provider = OSSL_PROVIDER_load(NULL, "rng");
        if (NULL == rng_provider) {
                ERR_RND("Failed to load rng provider\n");
                goto out;
        }  
...
}

int get_random_bytes(u_char *buffer, int length)
{
...
        EVP_RAND *rand = NULL;
        EVP_RAND_CTX *ctx = NULL;

        rng_provider_load();

rand = EVP_RAND_fetch(NULL, "DRBG", "provider=rng,fips=no");
        if (!rand) {
                ERR_RND("failed to fetch EVP_RAND\n");
                goto end;
        }

        ctx = EVP_RAND_CTX_new(rand, NULL);
        if (!ctx) {
                ERR_RND("failed to create EVP_RAND_CTX from EVP_RAND. rand = %p\n", rand);
                goto end;
        }

        if (!EVP_RAND_generate(ctx, buffer, length, 0, 0, NULL, 0)) {
                ERR_RND("failed to generate rand bytes. length = %d\n", length);               
                goto end;
        }
...
}

The binary crashed. Any constructive suggestions are highly welcomed.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a85d40 in ?? ()
(gdb) bt
#0  0x00007ffff7a85d40 in ?? ()
#1  0x00007ffff7cb42a2 in algorithm_do_this (provider=0x415b40, cbdata=cbdata@entry=0x7fffffffe1b0) at crypto/core_algorithm.c:120
#2  0x00007ffff7cc5e7e in ossl_provider_doall_activated (ctx=<optimized out>, cb=cb@entry=0x7ffff7cb41c0 <algorithm_do_this>, 
    cbdata=cbdata@entry=0x7fffffffe1b0) at crypto/provider_core.c:1423
#3  0x00007ffff7cb4461 in ossl_algorithm_do_all (libctx=0x0, operation_id=<optimized out>, provider=<optimized out>, 
    pre=pre@entry=0x7ffff7cb4680 <ossl_method_construct_precondition>, 
    reserve_store=reserve_store@entry=0x7ffff7cb4500 <ossl_method_construct_reserve_store>, 
    fn=fn@entry=0x7ffff7cb4580 <ossl_method_construct_this>, unreserve_store=0x7ffff7cb4560 <ossl_method_construct_unreserve_store>, 
    post=0x7ffff7cb4600 <ossl_method_construct_postcondition>, data=0x7fffffffe240) at crypto/core_algorithm.c:162
#4  0x00007ffff7cb4794 in ossl_method_construct (libctx=<optimized out>, operation_id=operation_id@entry=5, 
    provider_rw=provider_rw@entry=0x7fffffffe2c0, force_store=force_store@entry=0, mcm=mcm@entry=0x7fffffffe2d0, 
    mcm_data=mcm_data@entry=0x7fffffffe310) at crypto/core_fetch.c:153
#5  0x00007ffff7c8bf76 in inner_evp_generic_fetch (free_method=0x7ffff7c909f0 <evp_rand_free>, 
    up_ref_method=0x7ffff7c90a60 <evp_rand_up_ref>, new_method=0x7ffff7c90a80 <evp_rand_from_algorithm>, 
    properties=0x7ffff7a8f057 "provider=rng,fips=no", name=0x7ffff7a8f052 "DRBG", operation_id=5, prov=<optimized out>, 
    methdata=0x7fffffffe310) at crypto/evp/evp_fetch.c:312
#6  evp_generic_fetch (libctx=<optimized out>, operation_id=operation_id@entry=5, name=0x7ffff7a8f052 "DRBG", 
    properties=0x7ffff7a8f057 "provider=rng,fips=no", new_method=new_method@entry=0x7ffff7c90a80 <evp_rand_from_algorithm>, 
    up_ref_method=up_ref_method@entry=0x7ffff7c90a60 <evp_rand_up_ref>, free_method=0x7ffff7c909f0 <evp_rand_free>)
    at crypto/evp/evp_fetch.c:364
#7  0x00007ffff7c9118e in EVP_RAND_fetch (libctx=<optimized out>, algorithm=<optimized out>, properties=<optimized out>)
    at crypto/evp/evp_rand.c:288
#8  0x00007ffff7a8e44a in get_rnd_bytes (buffer=0x7fffffffe410 "", length=4) at rnd.c:120
#9  0x0000000000401199 in test (i=1, length=4) at test_get_rnd_bytes.c:10
#10 0x000000000040124e in main () at test_get_rnd_bytes.c:24

(gdb) f 1
#1  0x00007ffff7cb42a2 in algorithm_do_this (provider=0x415b40, cbdata=cbdata@entry=0x7fffffffe1b0) at crypto/core_algorithm.c:120
120	        map = ossl_provider_query_operation(provider, cur_operation,
(gdb) p *provider
$1 = {flag_initialized = 1, flag_activated = 1, flag_lock = 0x41a3b0, refcnt = 3, refcnt_lock = 0x0, activatecnt = 2, 
  name = 0x4194c0 "rng", path = 0x0, module = 0x0, init_function = 0x7ffff7a858c0, parameters = 0x41be30, libctx = 0x0, 
  store = 0x4062b0, error_lib = 128, error_strings = 0x415c30, teardown = 0x7ffff7a85d20, gettable_params = 0x0, get_params = 0x0, 
  get_capabilities = 0x0, self_test = 0x0, query_operation = 0x7ffff7a85d40, unquery_operation = 0x0, operation_bits = 0x0, 
  operation_bits_sz = 0, opbits_lock = 0x41ace0, handle = 0x0, ischild = 0, provctx = 0x41bcf0, dispatch = 0x7ffff7a87d20}

What is the purpose of ctx->ongoing ? It is used here

if (ctx->ongoing) {
    ERR_raise(ERR_HANDLE(ctx), VIGENERE_ONGOING_OPERATION);
    return 0;
}

Why would some one call set_ctx_params while using the algorithm? Is this to make it thread safe?

I want to try vigenere on WLS 2 with Ubuntu. The latest version has OpenSSL 1.1.1 installed, so I downloaded OpenSSL 3.0.11 and build it via:

$ ./Configure --prefix=/home/pmlinux64/local --openssldir=/home/pmlinux64/local/ssl -d
make
make install

I confirmed the installation is populated in the expected location:

$ ls /home/pmlinux64/local
bin include lib64 share ssl

When I try to build vigenere with alternative OpenSSL 3 location path, per README.md, it fails as shown below. Please advise on how to do a successful build.

$ cmake -DCMAKE_PREFIX_PATH=/home/pmlinux64/local -S . -B _build
CMake Error at CMakeLists.txt:13 (add_subdirectory):
The source directory

/home/pmlinux64/vigenere-main/libprov

does not contain a CMakeLists.txt file.

CMake Error at CMakeLists.txt:14 (include):
include could not find requested file:
libprov/cmake/provider.cmake

CMake Error at CMakeLists.txt:15 (setup_provider_openssl):
Unknown CMake command "setup_provider_openssl".

-- Configuring incomplete, errors occurred!

I'm in the process of trying to convert a cipher that was built in OSSL 1.1.1 by using the meth_new process (it's a multithreaded aes ctr cipher used in hpnssh). I obviously need to move this over to a provider. However, the documentation (at least that provided by OpenSSL) is a bit... almost useful but not quite. Is there a resource that you know of that can help? I've just got a lot of questions that are, likely, basic. I'm sorry for the random ask but I'm hitting a lot of walls right now and I'm really hoping there is a decent resource you could point me towards.

Thanks,

Chris

At the very least I'd expect it to have "provider=vignere" specified for it.

For the longest time during the development of OpenSSL 3.0, this mantra was uttered with some sort of regularity: know your provider.

The ramification of this is, of course, that with every provider, there should be some sort of documentation, so users can know the important bits and make good use of said provider.

This provider is lacking that part, there really is no documentation at all, and is thusly a poor example in that regard.

Adding an example documentation may also be another way to answer the concerns raised in #5

CI tests are currently failing. This is due to a bug in OpenSSL that has unspecified restrictions on unquoted property values; there is a fixup PR out (openssl/openssl#19998), so all that's needed to do is to wait for it to come through.

1. Why do you use the malloc/free functions instead of the OPENSSL_malloc/free?
2. Is the old way of generating the error files (using the mkerr.pl script) still relevant?