On 08.11.24 03:15, Bear Giles wrote:
> The first is that openssl has supported custom memory management for a
> very long time - I remember using it in the late 90s. The function is in
> crypto.h
>
> typedef void *(*CRYPTO_malloc_fn)(size_t num, const char *file, int line);
> typedef void *(*CRYPTO_realloc_fn)(void *addr, size_t num, const char
> *file,
> int line);
> typedef void (*CRYPTO_free_fn)(void *addr, const char *file, int line);
> int CRYPTO_set_mem_functions(CRYPTO_malloc_fn malloc_fn,
> CRYPTO_realloc_fn realloc_fn,
> CRYPTO_free_fn free_fn);
>
> The main benefit of this function is that it openssl-internal functions
> will use the same memory pool as your application. I know the current
> extension uses palloc/pfree but I didn't see a call to this function.
The problem with this kind of interface is that in PostgreSQL, the idea
is behind using palloc() is that you usually don't need to take care to
free the memory, because it is automatically freed at some appropriate
time (end of row, end of query, end of transaction, etc.). But an
external library like openssl doesn't know that. So it could happen
that PostgreSQL automatically frees some data structure that openssl
thinks should still exist.
This kind of problem definitely existed with libxml, which has a very
similar interface. So you'd have to do some very careful analysis
whether this would be safe for openssl. I suspect it's not worth the
bother.
> The second item is that openssl also has these wonderful functions:
>
> int CRYPTO_secure_malloc_init(size_t sz, size_t minsize);
> int CRYPTO_secure_malloc_done(void);
> void *CRYPTO_secure_malloc(size_t num, const char *file, int line);
> void *CRYPTO_secure_zalloc(size_t num, const char *file, int line);
> void CRYPTO_secure_free(void *ptr, const char *file, int line);
> void CRYPTO_secure_clear_free(void *ptr, size_t num,
> const char *file, int line);
> int CRYPTO_secure_allocated(const void *ptr);
> int CRYPTO_secure_malloc_initialized(void);
> size_t CRYPTO_secure_actual_size(void *ptr);
> size_t CRYPTO_secure_used(void);
>
> void OPENSSL_cleanse(void *ptr, size_t len);
>
> These functions address (at least) two potential vulnerabilities. First
> it tweaks the memory block so it will never be written to the swap file,
> and second it (iirc) also tweaks the memory block to reduce the access
> permissions further than usual.
PostgreSQL does do this kind of thing already, see explicit_bzero().
Maybe we could do more. This would need a more specific analysis and
proposal.
