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

Implement alloc-or-die #134

Closed olabini closed 6 years ago

olabini commented 6 years ago

So, we have a large amount of malloc-and-check in our code base. However, libgcrypt, and by extension libotr, sometimes dies when allocation fails (using xalloc and so on). That means we already have alloc-or-die semantics in some parts of the code.

Since we can't really change those dynamics, and if we are running out of memory in such a severe way that we can't malloc, maybe the right approach is for us to change the allocation semantics in the rest of the library to simply use xalloc and the like instead of checking all over the place. This might simplify our code base significantly, and reduce a lot of exposure to attacks.

claucece commented 6 years ago

Mmm.. I'm not sure.. what kind of exposure attacks?

olabini commented 6 years ago

If we miss a place checking the result of malloc, there is the possibility for an attacker to use that. (long shot, yes) =)

claucece commented 6 years ago

Then, maybe, we should really check the return of malloc, everywhere. I'm not very comfortable with xalloc.

olabini commented 6 years ago

Sure. But the point is that we already have xmalloc functionality in some parts of our code base, because of dependencies. So in some cases, running out of memory will kill the process. We can't stop that.

claucece commented 6 years ago

We can't stop that.

For me that is completely fine, because that is not our library per se.

olabini commented 6 years ago

OK, we have decided to use alloc-or-die semantics.