Is memcpy secure?

[Olga Sayenko]

Hi,

I am trying to make sure that my data doesn't show up anywhere outside
my process unencrypted. I am concerned that if I use memcpy, the bytes
copied will end up in some memory somewhere after I am done with it.
Am I being paranoid?


Thanks,

Olga

 

[Clark Cox]

Hi,

I am trying to make sure that my data doesn't show up anywhere outside
my process unencrypted. I am concerned that if I use memcpy, the bytes
copied will end up in some memory somewhere after I am done with it.

It will be in memory somewhere: where you copied it from, and where you
copied it to

Am I being paranoid?

I'd say you're being paranoid. <OT>If you're on a system with protected
memory, memcpy is not going to copy outside of your process. If you're
on a system without proected memory, then there's nothing you can do to
*hide* your data from other applications. The use of memcpy is
irrrelevant.</OT>

 

[Walter Roberson]

:I am trying to make sure that my data doesn't show up anywhere outside
:my process unencrypted. I am concerned that if I use memcpy, the bytes
:copied will end up in some memory somewhere after I am done with it.
:Am I being paranoid?

Depends on your OS and architecture. Generally speaking, the Linux-type
people consider it a bug if memcpy is not as efficient as possible,
but you could be on an unusual architecture on which efficiency
involved sending a page-sized copy request to a hardware dma unit.


One thing to keep in mind is that unless you take special care,
the page containing your data might get swapped out to disk, possibly
multiple times.

 

[Walter Roberson]

:I'd say you're being paranoid. <OT>If you're on a system with protected
:memory: memcpy is not going to copy outside of your process.

On -any- system, memcpy is likely to involve moving bytes through
cpu and hardware registers that are "owned" by the OS rather than
by any one process.

Calling conventions often specify that particular registers may be
overwritten by system calls, so one runs into the theoretical
possibility that the value of a register after a system call by process
A might happen to have been set by work on behalf of process B.

 

[Christian Bau]

Hi,

I am trying to make sure that my data doesn't show up anywhere outside
my process unencrypted. I am concerned that if I use memcpy, the bytes
copied will end up in some memory somewhere after I am done with it.
Am I being paranoid?

Yes, but are you paranoid enough?

Seriously, memcpy will not be a special case. It won't do anything that
straightforward C code couldn't do. I would be more worried about the
data that was in a memory block that gets free()d.

 

[Olga Sayenko]

:I am trying to make sure that my data doesn't show up anywhere outside
:my process unencrypted. I am concerned that if I use memcpy, the bytes
:copied will end up in some memory somewhere after I am done with it.
:Am I being paranoid?

Depends on your OS and architecture. Generally speaking, the Linux-type
people consider it a bug if memcpy is not as efficient as possible,
but you could be on an unusual architecture on which efficiency
involved sending a page-sized copy request to a hardware dma unit.

It's Linux and not intended for any special architecture.

One thing to keep in mind is that unless you take special care,
the page containing your data might get swapped out to disk, possibly
multiple times.

How would I prevent this?


Thanks,

Olga

 

[Olga Sayenko]

Yes, but are you paranoid enough?

Finally, someone understands!

Seriously, memcpy will not be a special case. It won't do anything that
straightforward C code couldn't do. I would be more worried about the
data that was in a memory block that gets free()d.

Wouldn't setting buffers to null characters when I am done with them
take care of this?

 

[Peter Pichler]

Yes, but are you paranoid enough?

Seriously, memcpy will not be a special case. It won't do anything that
straightforward C code couldn't do. I would be more worried about the
data that was in a memory block that gets free()d.

Or indeed in any memory block, full stop. *Any* memory can be swapped to
a harddisk, for example.

 

[Richard Heathfield]

Finally, someone understands!

He is merely lulling you into a false sense of insecurity.

Wouldn't setting buffers to null characters when I am done with them
take care of this?

Yes. The quicker you do it, the better. For example, say you want to
calculate an MD5 hash of a challenge-response; you have a password you've
just this second captured from your user, and you have a challenge-response
buffer large enough to store the challenge (from the server) and the
password. First, memcpy the challenge (which is in clear anyway) into the
buffer (better still, do this before capturing the password!), then memcpy
the password into the challenge-response buffer, *immediately* zeroise the
original, do the hash, and then wipe out the password part of the
challenge-response buffer too.

Oh, yeah, and don't forget to wear a foil hat. Hey, you never know, right?

 

[Sidney Cadot]

Or indeed in any memory block, full stop. *Any* memory can be swapped to
a harddisk, for example.

This last statement is not correct.

On most OS'es it's possible, through system-specific extentions, to
request a block of memory that is non-swappable. Indeed, this is what
any program doing cryptographically sensitive stuff must do at some
point. Other possible sources of leaking sensitive information (e.g.,
via no-longer used memory blocks, or the stack, or even the L1/L2 cache)
must be considered as well. This is entirely impossible in Standard C of
course

Best regards,

Sidney

 

[CBFalconer]

Finally, someone understands!


Wouldn't setting buffers to null characters when I am done with
them take care of this?

Nothing will do other than designing a system from the
fundamentals up. Start with no long term storage, so that power
off wipes everything. This means the OS will have to boot from
the network. Maybe we can insist on some checks so the network
doesn't sneak a spy in. Then the reading and writing routines
have built in encryption. Who stores the keys, for how long, and
why? Etc. etc. ad nauseum.

Of course we have to guard that system, or some evil spy will
sneak in and replace the ROMS that do the initial booting and
checking. Hire at least three shifts of armed guards, and ensure
they are trustworthy. Do all the programming (including system
programs, utilities, etc.) yourself, because you can't trust
anybody. Pray. Make human sacrifices.

Now that you feel all warm and safe and comfy, you can relax.

 

[Andras Tantos]

Hi,

Finally, someone understands!


Wouldn't setting buffers to null characters when I am done with them
take care of this?

That's one consideration. But also avoid any functions that re-allocate
memory (realloc()). Use free-malloc in that case.

Take compiler optimization into accout. In some cases the compiler might
optimize out your zeroing code after finding out that the variable that you
are clearing is already dead.

Make sure (if you can) that the process cannot be debugged.

As others have said: make sure your processes memory space cannot be moved
to permanent storage due to swapping or hibernation for example.

Make sure that the whole information pass is secure. There's no reason
protecting the clear-text password in your code for example if it got copied
all around in the widget code you're using.

Never pass sensitive information to code that you don't trust. This means
shared libraries and even your own executable unless you made sure of it's
authenticity (use digital signatures).

Even after all of these you cannot do much if the OS or an OS component
tries to track your code. Or if someone hooks up a HW debugger. Or a logic
analizer to decode memory cycles. Or, or, or... There's no true security.
Only security that's good enough for not being worth while braking.

 

[Olga Sayenko]

Nothing will do other than designing a system from the
fundamentals up. Start with no long term storage, so that power
off wipes everything. This means the OS will have to boot from
the network. Maybe we can insist on some checks so the network
doesn't sneak a spy in. Then the reading and writing routines
have built in encryption. Who stores the keys, for how long, and
why? Etc. etc. ad nauseum.

Of course we have to guard that system, or some evil spy will
sneak in and replace the ROMS that do the initial booting and
checking. Hire at least three shifts of armed guards, and ensure
they are trustworthy. Do all the programming (including system
programs, utilities, etc.) yourself, because you can't trust
anybody. Pray. Make human sacrifices.

Now that you feel all warm and safe and comfy, you can relax.

Exaaaactly! Armed guards and human sacrifices are exactly what I had
in mind, but the silly, silly users - all they want to do buy Britney
Spears CD's online and not get their credit card numbers captured.

 

[Walter Roberson]

|[email protected] (Walter Roberson) wrote in message
|It's Linux and not intended for any special architecture.

|> One thing to keep in mind is that unless you take special care,
|> the page containing your data might get swapped out to disk, possibly
|> multiple times.

|How would I prevent this?

On Linux? mlock()

http://www.die.net/doc/linux/man/man2/mlock.2.html


There might be other methods too. On IRIX, there is mpin() which
is similar to mlock() except it counts locks instead of just
having locked vs unlocked.

 

[Christian Bau]

Exaaaactly! Armed guards and human sacrifices are exactly what I had
in mind, but the silly, silly users - all they want to do buy Britney
Spears CD's online and not get their credit card numbers captured.

If they buy Britney Spears then they deserve anything they get...

But there are several levels of security, depending on the situation:

a. Malicious entity has physical access to your computer either before
or after the action.

b. Malicious entity controls software running with high set of
permissions (root level) on your computer.

c. Malicious entity controls software running with low set of
permissions (user level) on your computer.

d. Malicious entity can intercept messages sent from your computer to
another computer.

e. Malicious entity tricks you into doing things you shouldn't do.

Each situation is different. The situation you describe has nothing to
do with memcpy; the most likely problem (b), (c) or (e). Using (b)
someone may be able to capture anything you type in, no matter what your
software does.

 

[Richard Bos]

:I'd say you're being paranoid. <OT>If you're on a system with protected
:memory: memcpy is not going to copy outside of your process.

On -any- system, memcpy is likely to involve moving bytes through
cpu and hardware registers that are "owned" by the OS rather than
by any one process.

Yes. However, the same thing is true of _all_ code which uses those
bytes. The only way to guarantee that the bytes are not passes to the
OS's property is not using them at all, ever, making the data less than
fully useful. memcpy() is no exception to this, neither positively nor
negatively.

Richard

 

[Frank Slootweg]

As others have said: make sure your processes memory space cannot be moved
to permanent storage due to swapping or hibernation for example.

This should be done for *performance* reasons, not for *security*
reasons. The swap area should only be accessible to the super user (the
OP is using Linux) and the super user can get into the process address
space anyway, whether on (swap) disk (/dev/[r]dsk) or in memory
(/dev/[k]mem).

 

[Walter Roberson]

:> As others have said: make sure your processes memory space cannot be moved
:> to permanent storage due to swapping or hibernation for example.

: This should be done for *performance* reasons, not for *security*
:reasons. The swap area should only be accessible to the super user (the
:OP is using Linux) and the super user can get into the process address
:space anyway, whether on (swap) disk (/dev/[r]dsk) or in memory
/dev/[k]mem).

You are assuming, Frank, access while the system is still running.
If the system is decommissioned (or the drive stolen), it is
more secure for the sensitive data to never have been swapped to
disk, than to assume that disk-scrubbing procedures will be used
before the disk was made available.

 

[Christian Bau]

As others have said: make sure your processes memory space cannot be moved
to permanent storage due to swapping or hibernation for example.

This should be done for *performance* reasons, not for *security*
reasons. The swap area should only be accessible to the super user (the
OP is using Linux) and the super user can get into the process address
space anyway, whether on (swap) disk (/dev/[r]dsk) or in memory
(/dev/[k]mem).

Unlike memory, the swap area is also accessible to someone who opens
your computer and takes the harddisk away.

 

[Frank Slootweg]

As others have said: make sure your processes memory space cannot be moved
to permanent storage due to swapping or hibernation for example.

This should be done for *performance* reasons, not for *security*
reasons. The swap area should only be accessible to the super user (the
OP is using Linux) and the super user can get into the process address
space anyway, whether on (swap) disk (/dev/[r]dsk) or in memory
(/dev/[k]mem).

Unlike memory, the swap area is also accessible to someone who opens
your computer and takes the harddisk away.

That assumes physical access to the machine. If someone has physical
access to the machine, *all* bets are off, not just this one.