search

otrv4 / libotr-ng

A new implementation of OTR with support for version 4. This is a mirror of https://bugs.otr.im/otrv4/libotr-ng
Other
43 stars 9 forks source link

Ensure we allocate memory in a safe way #136

Closed olabini closed 6 years ago

olabini commented 6 years ago

See https://bugs.otr.im/lib/libotr/issues/23

claucece commented 6 years ago

As far as I know, we were already using the way to allocate of libgrcrypt, but we can recheck again.

olabini commented 6 years ago

For example, in some places we are putting secret data into stack-allocated buffers for a short amount of time. We should investigate and make sure secret data is always put into "secure memory arenas". It might also be worth adding our own macros/aliases for these things in one place, so we can easily evolve the implementations (just as for #141).

claucece commented 6 years ago

@olabini Agreed! There is also some security functions for this on libgcrytp (like gcry_mpi_snew), that we should use.

olabini commented 6 years ago

A lot of allocation of secure objects is happening on the stack, since we heavily employ _p style objects. For now, this story is not about fixing this, instead it's about fixing the places where we do actual allocation.

If we want to fix the wider issue, we should revisit the manifest array style of defining structures, and also make sure to allocate external _p structures on the heap. We should create a different issue for this, if we want to do it.