Securing a C++ class

[Jonathan Lee]

(Sorry to anyone who saw this in sci.crypt as well, but I'm curious
what both groups have to say)

Hi all,
I am writing a large integer library for math related work. In
principle, it could be used for security except that it doesn't
securely allocate or clear memory. Maybe it doesn't do other things,
but my question is basically about the memory allocation. Suppose
another programmer, who is better at such things, wanted to "replace"
the alloc with a secured version. Can I facilitate this? Allow them
to subclass, and make the allocator a virtual function? Or would such
a designer just prefer to rewrite the function? Or overload new[] and
delete[] so it happens without touching the class?
Any thoughts?

--Jonathan

 

[Balog Pal]

I am writing a large integer library for math related work. In
principle, it could be used for security except that it doesn't
securely allocate or clear memory. Maybe it doesn't do other things,
but my question is basically about the memory allocation. Suppose
another programmer, who is better at such things, wanted to "replace"
the alloc with a secured version. Can I facilitate this? Allow them
to subclass, and make the allocator a virtual function? Or would such
a designer just prefer to rewrite the function? Or overload new[] and
delete[] so it happens without touching the class?

Please explain the real-life problem.
What can be 'secure' or 'not secure' in a memory allocator?

 

[Jonathan Lee]

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.

--Jonathan

 

[Victor Bazarov]

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.

IOW you're talking about the ability for the customer to provide their
own allocators (which might do what you describe here along with other
things). Yes? So, it really has nothing to do specifically with
security. Or did I misunderstand something?

V

 

[red floyd]

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.

Since swapping to disk is under the control of the OS, some OS'en do
not
allow you to allocate memory as "non-swappable", you may be toast.

 

[Victor Bazarov]

Since swapping to disk is under the control of the OS, some OS'en do
not
allow you to allocate memory as "non-swappable", you may be toast.

Toast? Why? It would only mean that for such an OS the users of the
OP's library won't attempt to use those for security if not swapping is
important. How would it affect the OP's efforts to provide a way to
plug in a custom[er's] allocator?

V

 

[Balog Pal]

"Jonathan Lee" <[email protected]>

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.

 

[Jonathan Lee]

IOW you're talking about the ability for the customer to provide their
own allocators (which might do what you describe here along with other
things).  Yes?

Yes. The security context was just an example. I'm more interested in
the best practice for allowing a user to provide their own allocator,
as you say.

--Jonathan

 

[Noah Roberts]

(Sorry to anyone who saw this in sci.crypt as well, but I'm curious
what both groups have to say)

Hi all,
I am writing a large integer library for math related work. In
principle, it could be used for security except that it doesn't
securely allocate or clear memory. Maybe it doesn't do other things,
but my question is basically about the memory allocation. Suppose
another programmer, who is better at such things, wanted to "replace"
the alloc with a secured version. Can I facilitate this? Allow them
to subclass, and make the allocator a virtual function? Or would such
a designer just prefer to rewrite the function? Or overload new[] and
delete[] so it happens without touching the class?
Any thoughts?

There may be reasons why you don't want to, but have you thought of
simply using the Allocator concept from the std?

 

[Jonathan Lee]

There may be reasons why you don't want to, but have you thought of
simply using the Allocator concept from the std?

No, actually, I hadn't thought of that. You mean write it as a
template class instead of a base class? That might work pretty
well..

--Jonathan

 

[James Kanze]

Jonathan Lee wrote:

I am writing a large integer library for math related work. In
principle, it could be used for security except that it doesn't
securely allocate or clear memory. Maybe it doesn't do other things,
but my question is basically about the memory allocation. Suppose
another programmer, who is better at such things, wanted to "replace"
the alloc with a secured version. Can I facilitate this? Allow them
to subclass, and make the allocator a virtual function? Or would such
a designer just prefer to rewrite the function? Or overload new[] and
delete[] so it happens without touching the class?
Any thoughts?

There may be reasons why you don't want to, but have you thought of
simply using the Allocator concept from the std?

That only works if the classes in question are templates. If
they're already templates (and obviously, even without the
allocators, std::vector has to be a template), fine. But if the
classes are reasonably big and complex, and there's no other
reason to make them templates, there are probably simpler
solutions.

The one that occurs to me, which would definitely work in
practice, is to declare and define (static) member functions
which are used for the allocation, and put their implementation
in a separate source file from the rest. A client who wanted to
provide their own allocator only has to implement these
functions, and specify the object file to the linker *before*
specifying the library.

 

[Balog Pal]

That only works if the classes in question are templates.

For the originally mentioned problem using std:: classes is hardly an
option. How do you know std::vector does not write its content somewhere in
a file, a hidden stream?

Or doesn't use copies of content on stack, or memory blocks got via the
usual malloc/new or a compiler-internal store, that get properly
deallocated before returning, yet avoided the promised control.

 

[red floyd]

Since swapping to disk is under the control of the OS, some OS'en do
not
allow you to allocate memory as "non-swappable", you may be toast.

Toast?  Why?  It would only mean that for such an OS the users of the
OP's library won't attempt to use those for security if not swapping is
important.  How would it affect the OP's efforts to provide a way to
plug in a custom[er's] allocator?

By toast, I meant "out of luck", in that if the OS doesn't provide the
feature,
he can't do what he wants.

 

[Jonathan Lee]

The one that occurs to me, which would definitely work in
practice, is to declare and define (static) member functions
which are used for the allocation, and put their implementation
in a separate source file from the rest.

Thanks, James. Looks like I have a few options to consider.

--Jonathan

 

[Jonathan Lee]

For the originally mentioned problem using std:: classes is hardly an
option. How do you know std::vector does not write its content somewhere in
a file, a hidden stream?

Hi Balog Pal,
Thanks for all your input. Honestly, though, the security isn't much
of a concern to me. I'm more interested in the class design. I expect
that the security will be _someone else's_ concern. I would just like
to design the class to ease their job.

--Jonathan

 

[Victor Bazarov]

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.
Since swapping to disk is under the control of the OS, some OS'en do
not
allow you to allocate memory as "non-swappable", you may be toast.

Toast? Why? It would only mean that for such an OS the users of the
OP's library won't attempt to use those for security if not swapping is
important. How would it affect the OP's efforts to provide a way to
plug in a custom[er's] allocator?

By toast, I meant "out of luck", in that if the OS doesn't provide the
feature,
he can't do what he wants.

I don't see how this is applicable. If OS doesn't allow to allocate
non-swappable, the OP can still provide the library with a way for the
user of that library to employ user's own allocators. Those issues are
not connected, methinks. The OP didn't say he needed to provide the
allocator for non-swappable memory, he said he needed to have a way for
somebody else to plug theirs in. Maybe I misunderstood something. From
the OP's message: << Suppose another programmer, who is better at such
things, wanted to "replace" the alloc with a secured version. Can I
facilitate this? >>

V

 

[red floyd]

red floyd 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.
Since swapping to disk is under the control of the OS, some OS'en do
not
allow you to allocate memory as "non-swappable", you may be toast.
Toast?  Why?  It would only mean that for such an OS the users of the
OP's library won't attempt to use those for security if not swapping is
important.  How would it affect the OP's efforts to provide a way to
plug in a custom[er's] allocator?

By toast, I meant "out of luck", in that if the OS doesn't provide the
feature,
he can't do what he wants.

I don't see how this is applicable.  If OS doesn't allow to allocate
non-swappable, the OP can still provide the library with a way for the
user of that library to employ user's own allocators.  Those issues are
not connected, methinks.  The OP didn't say he needed to provide the
allocator for non-swappable memory, he said he needed to have a way for
somebody else to plug theirs in.  Maybe I misunderstood something.  From
the OP's message: << Suppose another programmer, who is better at such
things, wanted to "replace" the alloc with a secured version. Can I
facilitate this? >>

He wanted to be able to prevent memory from being swapped to disk. If
that's under the control of the OS, and there's no API call to prevent
it,
then he's SOL.

From the PP of my original response:

"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*." (emphasis mine).

 

[Victor Bazarov]

red floyd 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.
Since swapping to disk is under the control of the OS, some OS'en do
not
allow you to allocate memory as "non-swappable", you may be toast.
Toast? Why? It would only mean that for such an OS the users of the
OP's library won't attempt to use those for security if not swapping is
important. How would it affect the OP's efforts to provide a way to
plug in a custom[er's] allocator?
By toast, I meant "out of luck", in that if the OS doesn't provide the
feature,
he can't do what he wants.

I don't see how this is applicable. If OS doesn't allow to allocate
non-swappable, the OP can still provide the library with a way for the
user of that library to employ user's own allocators. Those issues are
not connected, methinks. The OP didn't say he needed to provide the
allocator for non-swappable memory, he said he needed to have a way for
somebody else to plug theirs in. Maybe I misunderstood something. From
the OP's message: << Suppose another programmer, who is better at such
things, wanted to "replace" the alloc with a secured version. Can I
facilitate this? >>

He wanted to be able to prevent memory from being swapped to disk. If
that's under the control of the OS, and there's no API call to prevent
it,
then he's SOL.

Who is "he" here? The OP? If you care to reread the thread from the
start, the OP never wanted to provide a "secure allocator" *himself*.
That is why I asked for the reason he (the OP) would be "toast". Or did
you not mean the OP when you said "you"? Or does it depend on what the
meaning of "is" is?

From the PP of my original response:

"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*." (emphasis mine).

Yes, so? Why would the OP be "toast", again? It's *whoever wants to
provide* this "secure memory allocator" on the OS that doesn't have
that, right? No? <wink wink, nudge nudge>

Methinks we're going in circles, so I'm just gonna go ahead and step out
of it for a while, OK? Feel free to keep going while I'm not here.

V