[gnutls-devel] GnuTLS | Use custom free/realloc for GMP to safely delete temporary secrets (!1554)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Fri Mar 18 11:23:15 CET 2022




Tobias Heider commented:


@dueno conflicting overrides indeed seem to be a problem...

In the guile case i think the following hack could solve the problem:

```
void (*reallocfunc) (void *, size_t);
void (*freefunc) (void *, size_t);
void (*defreallocfunc) (void *, size_t);
void (*deffreefunc) (void *, size_t);

/* Get previous allocators */
mp_get_memory_functions(NULL, &reallocfunc, &freefunc);

/* Reset to defaults */
mp_set_memory_functions(NULL, NULL, NULL);

/* Get default allocators */
mp_get_memory_functions(NULL, &defreallocfunc, &deffreefunc);

/* See if free or realloc have been overriden before */
if (reallocfunc != defreallocfunc || freefunc != deffreefunc)
    goto donothing;

/* Overload GMP allocators with safe alternatives */
mp_set_memory_functions(NULL, gnutls_realloc_zero, gnutls_free_zero);
```

This probably isn't the most elegant solution but reading the gmp code and documentation i think it should do the job.

What i am really more worried about is applications overriding the allocators when you actually want FIPS compliance and secure deletion.
The best solution in the long term would probably be sth like a `gmp_ctx` which can be passed to every gmp function call instead of a single global setting. The `gmp_ctx` then stores the pointers to the allocator functions so that every caller can pass their own allocators.

I can't really think of an easy fix other than just saying: don't override gmp allocators if want things to be securely deleted for you, otherwise you are on yourself.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1554#note_879633463
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20220318/ba41dcca/attachment.html>


More information about the Gnutls-devel mailing list