Re: Securing a C++ class
"Jonathan Lee" <chorus@shaw.ca>
On Jul 23, 1:48 pm, "Balog Pal" <p...@lib.hu> wrote:
Please explain the real-life problem.
What can be 'secure' or 'not secure' in a memory allocator?
A secure memory allocator might ensure that the contents of that
memory are erased on deallocation, or that the memory is never swapped
to hard disk. This isn't something I would need to happen for a
general BigInt class -- the usual new[] and delete[] would be fine. On
the other hand, a SecureBigInt class would almost be identical, but
would require calls to mlock() on linux, or SecureZeroMemory on
Windows, for example.
I see. Sounds like a race for false sense of security to mee -- that may
leave the actual system in more danger if you just left stuff as is,
avoiding extra complexity on the road too.
Memory content paged to the swap sounds like danger, but if you go after it
may realize, that an attacker capable reading your swap file is also capable
to capture it from your process directly, including your 'locked' pages.
Also while you process the content copies are created you hardly can claim
to have control -- and memory of the temporary area used by compiler, the
stack, etc can be swapped the same.
Clearing up stuff is even more definitely not job of the deallocator but of
the program when done with the content.
Creating hooks for is not hard technicly -- just issue an interface like
malloc/free/realloc and make your lib use that exclusively, and make the
implementation replaceable (or calling hooks at proper points).
But actual security shall be designed in on different levels. And do it the
prescribed way, creating the threat matrix, attack and defence scenarios,
etc, then install the countermeasures.
You can't plug in security -- whoever attempted that fall on face.