By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,171 Members | 1,037 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

Is memcpy secure?

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
36 Replies


P: n/a
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:
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>

Nov 14 '05 #2

P: n/a
In article <50**************************@posting.google.com >,
Olga Sayenko <sa*****@yahoo.com> wrote:
: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.
--
Oh, to be a Blobel!
Nov 14 '05 #3

P: n/a
In article <clarkcox3-7CDEAB.21383810012004@localhost>,
Clark Cox <cl*******@mac.com> wrote:
: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.

--
Oh, yeah, an African swallow maybe, but not a European swallow.
That's my point.
Nov 14 '05 #4

P: n/a
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:
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.
Nov 14 '05 #5

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message news:<bt**********@canopus.cc.umanitoba.ca>...
In article <50**************************@posting.google.com >,
Olga Sayenko <sa*****@yahoo.com> wrote:
: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
Nov 14 '05 #6

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote in message news:<ch*********************************@slb-newsm1.svr.pol.co.uk>...
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:
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?


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?
Nov 14 '05 #7

P: n/a
"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote...
(Olga Sayenko) wrote:
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.


Or indeed in any memory block, full stop. *Any* memory can be swapped to
a harddisk, for example.
Nov 14 '05 #8

P: n/a
Olga Sayenko wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote in message
news:<ch*********************************@slb-newsm1.svr.pol.co.uk>...
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:
> Am I being paranoid?


Yes, but are you paranoid enough?


Finally, someone understands! :)


He is merely lulling you into a false sense of insecurity.
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?


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?
:-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #9

P: n/a
Peter Pichler wrote:
"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote...
(Olga Sayenko) wrote:
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.

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
Nov 14 '05 #10

P: n/a
Olga Sayenko wrote:
<ch***********@cbau.freeserve.co.uk> wrote in message
sa*****@yahoo.com (Olga Sayenko) wrote:
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?


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?


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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #11

P: n/a
> > > 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?


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?


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.

--
Regards,
Andras Tantos
<http://andras.tantos.homedns.org>
Nov 14 '05 #12

P: n/a
CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...
Olga Sayenko wrote:
<ch***********@cbau.freeserve.co.uk> wrote in message
sa*****@yahoo.com (Olga Sayenko) wrote:

> 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?


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?


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.
Nov 14 '05 #13

P: n/a
In article <50**************************@posting.google.com >,
Olga Sayenko <sa*****@yahoo.com> wrote:
|r*******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message news:<bt**********@canopus.cc.umanitoba.ca>...

|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.
--
WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,v onNeumann}D ?
Nov 14 '05 #14

P: n/a
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:
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.
Nov 14 '05 #15

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
In article <clarkcox3-7CDEAB.21383810012004@localhost>,
Clark Cox <cl*******@mac.com> wrote:
: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
Nov 14 '05 #16

P: n/a
Andras Tantos <an***********@yahoo.com> wrote:
[deleted]
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).
Nov 14 '05 #17

P: n/a
In article <40***********************@news.wanadoo.nl>,
Frank Slootweg <th**@ddress.is.invalid> wrote:
:Andras Tantos <an***********@yahoo.com> wrote:

:> 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.

--
Scintillate, scintillate, globule vivific
Fain would I fathom thy nature specific.
Loftily poised on ether capacious
Strongly resembling a gem carbonaceous. -- Anon
Nov 14 '05 #18

P: n/a
In article <40***********************@news.wanadoo.nl>,
Frank Slootweg <th**@ddress.is.invalid> wrote:
Andras Tantos <an***********@yahoo.com> wrote:
[deleted]
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.
Nov 14 '05 #19

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <40***********************@news.wanadoo.nl>,
Frank Slootweg <th**@ddress.is.invalid> wrote:
Andras Tantos <an***********@yahoo.com> wrote:
[deleted]
> 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.
Nov 14 '05 #20

P: n/a
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
In article <40***********************@news.wanadoo.nl>,
Frank Slootweg <th**@ddress.is.invalid> wrote:
:Andras Tantos <an***********@yahoo.com> wrote:

:> 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.


Good point. While you're at it, you (the OP) might also want to make
sure that the system never crashes and leaves a crash dump on disk.
Nov 14 '05 #21

P: n/a
Frank Slootweg wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <40***********************@news.wanadoo.nl>,
Frank Slootweg <th**@ddress.is.invalid> wrote:

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.


You're wrong: not all bets are off. For example, I'm willing to bet that
you would be much less likely to find sensitive information on the
swap disk if a cryptographic application is properly written to use
non-swappable memory. In other words, this diminishes the risk of leaks
quite significantly. Which is the best you can do, since, of course,
perfect security is not attainable in practice.

I must say I fail to see the point you are trying to make. That a writer
of cryptographically sensitive software shouldn't care about the
possibility of swapping (as it gains no extra security, as per your view)?

By the same reasoning, you could also dismiss replacing a typed-in
password on screen by asterixes (or plain nothing), since it doesn't
truly help against an observer who is looking over your shoulder?

Best regards,

Sidney

Nov 14 '05 #22

P: n/a
In comp.security.misc Frank Slootweg <th**@ddress.is.invalid> wrote:
Andras Tantos <an***********@yahoo.com> wrote:
[deleted]
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).


It's actually fairly challenging to peek into your process memory at
precisely the right time to pull out the key/password/sensitive info.

On the other hand, if it's sent out to swap space, a person who
discovered a root exploit a day later could potentially find this info
from browsing through the swap space.

Yes, the first is a problem, but it's relatively low risk and there's
not a whole lot you can do about it without a stronger security model
(something like SELinux, for example). The second takes considerably
less skill and is a higher risk. That's why it makes sense to take
reasonable precautions to lock these pages into memory.

--

That's News To Me!
ne******@comcast.net
Nov 14 '05 #23

P: n/a
Sidney Cadot <si****@jigsaw.nl> wrote:
Frank Slootweg wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <40***********************@news.wanadoo.nl>,
Frank Slootweg <th**@ddress.is.invalid> wrote:

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.


You're wrong: not all bets are off. For example, I'm willing to bet that
you would be much less likely to find sensitive information on the
swap disk if a cryptographic application is properly written to use
non-swappable memory. In other words, this diminishes the risk of leaks
quite significantly. Which is the best you can do, since, of course,
perfect security is not attainable in practice.


I already conceded that point, non-swappable memory versus swappable
memory, in my response to Walter.

What I was addressing now, was Christian's comment, which implied
physical access to the machine. If a malicious person has physical to
the machine, that opens a whole other can of worms. That was what I was
saying. Yes, some systems can be have reasonable security even with
physical access, but for most run of the mill systems, that will not be
the case, especially for run of the mill Intel systems which probably
will be used here (AFAIK, the OP has not mentioned any specific machine,
only "Linux".)

[deleted]
Nov 14 '05 #24

P: n/a
In comp.security.misc Olga Sayenko <sa*****@yahoo.com> wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote in message news:<ch*********************************@slb-newsm1.svr.pol.co.uk>...
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:
> 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? 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?


Beware the compiler optimizations. If you zero it out, and then
immediately free() it, the compiler may say "it's just going to be
free()d, so why bother zeroing it first? that just takes time! I'll
just optimize out that part of the code, and release the memory with
the plaintext password still in it."

As the previous poster asked, "are you paranoid enough?" ;)

Damian Menscher
--
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <me******@uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
Nov 14 '05 #25

P: n/a
>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?


Worry about the original memory, too, not just the copy.

Always use the pointer to the sensitive data as the *FIRST* argument,
never the second. Don't make copies of sensitive data. Destroy
them.

Remember that the US government has physical access to just about
any machine if they want it bad enough. (Two Mars rovers are a
notable exception.) No, you guys in Europe or Australia aren't safe.
If you hear the door breaking in, can you press the switch setting
off the explosives on the hard disk fast enough?

Always remember that SSL is a security method used by a thief (the
web site operator) to ensure that your credit card number is safely
delivered into his hands so he can steal from it before anyone else
gets a chance to.

Gordon L. Burditt
Nov 14 '05 #26

P: n/a
In article <bv********@library1.airnews.net>,
Gordon Burditt <go***********@sneaky.lerctr.org> wrote:
:>I am trying to make sure that my data doesn't show up anywhere outside
:>my process unencrypted.

:Always use the pointer to the sensitive data as the *FIRST* argument,
:never the second.

Surely that would depend on the ABI (Application Binary Interface) ?

For example, I have seen ABIs in which up to the first 6 (I think it
was) leading data values were passed in registers, but everything
from the first pointer onwards was passed on the stack. In such
an architecture, to be secure you would want to cast your pointer
into a long and make sure it was placed early on -- but blindly
passing a pointer as the first parameter would end up with -nothing-
being passed in registers.
--
Look out, there are llamas!
Nov 14 '05 #27

P: n/a
In <bu**********@news.ks.uiuc.edu> Damian Menscher <me***************@uiuc.edu> writes:
In comp.security.misc Olga Sayenko <sa*****@yahoo.com> wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote in message news:<ch*********************************@slb-newsm1.svr.pol.co.uk>...
In article <50**************************@posting.google.com >,
sa*****@yahoo.com (Olga Sayenko) wrote:

> 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?
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?


Beware the compiler optimizations. If you zero it out, and then
immediately free() it, the compiler may say "it's just going to be
free()d, so why bother zeroing it first? that just takes time! I'll
just optimize out that part of the code, and release the memory with
the plaintext password still in it."

As the previous poster asked, "are you paranoid enough?" ;)


If you are paranoid enough, you won't use a system that swaps memory to
the disk (if the system's power is cut at the right moment, all your
sensitive data may be on the swap partition, readily accessible to anyone
who has physical access to the disk) and you won't use an OS you haven't
written yourself and compiled with your own compiler.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #28

P: n/a
In <bv**********@canopus.cc.umanitoba.ca> ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <bv********@library1.airnews.net>,
Gordon Burditt <go***********@sneaky.lerctr.org> wrote:
:>I am trying to make sure that my data doesn't show up anywhere outside
:>my process unencrypted.

:Always use the pointer to the sensitive data as the *FIRST* argument,
:never the second.

Surely that would depend on the ABI (Application Binary Interface) ?

For example, I have seen ABIs in which up to the first 6 (I think it
was) leading data values were passed in registers, but everything
from the first pointer onwards was passed on the stack. In such
an architecture, to be secure you would want to cast your pointer
into a long and make sure it was placed early on -- but blindly
passing a pointer as the first parameter would end up with -nothing-
being passed in registers.


Registers aren't safe, either, in a multi-tasking OS: when another process
is scheduled for execution, they end up in memory :-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #29

P: n/a
>:>I am trying to make sure that my data doesn't show up anywhere outside
:>my process unencrypted.

:Always use the pointer to the sensitive data as the *FIRST* argument,
:never the second.

Surely that would depend on the ABI (Application Binary Interface) ?
Not really. memcpy() takes *POINTERS* to data, and the pointer
to where sensitive data used to be isn't particularly sensitive
after the sensitive data has been written over. USE memcpy() to
DESTROY (WRITE OVER) SENSITIVE DATA, NOT MAKE COPIES OF IT!
For example, I have seen ABIs in which up to the first 6 (I think it
was) leading data values were passed in registers, but everything
from the first pointer onwards was passed on the stack. In such
memcpy() doesn't take 6 arguments. The first argument is a pointer
to the destination buffer (sensitive data). The second argument
is a pointer to the source buffer (random trash). You don't get
to re-order the meaning of the arguments to memcpy() to suit your
ABI and your paranoia level.
an architecture, to be secure you would want to cast your pointer
into a long and make sure it was placed early on -- but blindly
passing a pointer as the first parameter would end up with -nothing-
being passed in registers.
It is unlikely that passing a pointer would cause a few bytes of
what the pointer pointed at to also be passed. Since the first
(pointer) argument of memcpy() is used to alter data being pointed
at, it can't use those bytes passed anyway, so what's the point in
passing them?.

memcpy() takes two pointer arguments. You *DO NOT* want to cast
that to a long (which is not necessarily big enough to hold a whole
pointer) before passing it. Doing so may cause a core dump of the
whole process, including the sensitive data, to be posted to
comp.lang.c.
Look out, there are llamas!


C does not support pointers to llamas. Also, llamas weigh too much
and tend to crack the motherboard, plus they smell really bad :-( .

Gordon L. Burditt
Nov 14 '05 #30

P: n/a
In article <bv********@library1.airnews.net>,
Gordon Burditt <go***********@sneaky.lerctr.org> wrote:
|>:>I am trying to make sure that my data doesn't show up anywhere outside
|>:>my process unencrypted.

|>:Always use the pointer to the sensitive data as the *FIRST* argument,
|>:never the second.

|>Surely that would depend on the ABI (Application Binary Interface) ?

|Not really. memcpy() takes *POINTERS* to data, and the pointer
|to where sensitive data used to be isn't particularly sensitive
|after the sensitive data has been written over. USE memcpy() to
|DESTROY (WRITE OVER) SENSITIVE DATA, NOT MAKE COPIES OF IT!

I see what you mean now. Your posting wasn't clear that you
were talking only about memcpy() -- you had appeared to be saying that
if you have a sensitive pointer in any function, then it should be
in the first argument, and I was asking about the reasoning of that.

:memcpy() takes two pointer arguments. You *DO NOT* want to cast
:that to a long (which is not necessarily big enough to hold a whole
:pointer) before passing it.

ANSI C -defines- long as being large enough to hold a pointer,
and guarantees that if you convert a pointer to a long and back
again (with no arithmetic operations on the long) then the result
will point to the original object.

But anyhow, I wasn't talking about memcpy() in particular, I was
meaning to refer to when one was constructing one's own functions
for dealing with pointers to sensitive data: if you must have
such functions, then better to have the data go in registers than
on the stack. The other poster did, though, have a very good point,
about process switching potentially resulting in the registers
getting rolled into memory.
:> Look out, there are llamas!

:C does not support pointers to llamas.

Not ANSI C, no, but there's gcc --with-llama-pointers
and a contingent that is pressing to get them into POSIX.L .
For more details, see http://www.llama-pointers.org .
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
Nov 14 '05 #31

P: n/a
In article <bv**********@canopus.cc.umanitoba.ca>,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
ANSI C -defines- long as being large enough to hold a pointer,
and guarantees that if you convert a pointer to a long and back
again (with no arithmetic operations on the long) then the result
will point to the original object.


That is news to me. And to many others. Including the guys who wrote the
C Standard.
Nov 14 '05 #32

P: n/a
In article <ch*********************************@slb-newsm1.svr.pol.co.uk>,
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
:In article <bv**********@canopus.cc.umanitoba.ca>,
: ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

:> ANSI C -defines- long as being large enough to hold a pointer,
:> and guarantees that if you convert a pointer to a long and back
:> again (with no arithmetic operations on the long) then the result
:> will point to the original object.

:That is news to me. And to many others. Including the guys who wrote the
:C Standard.

I'll cross-check my references when I next have an opportunity.

--
I predict that you will not trust this prediction.
Nov 14 '05 #33

P: n/a
On 29 Jan 2004 20:11:26 GMT, in comp.lang.c ,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
In article <ch*********************************@slb-newsm1.svr.pol.co.uk>,
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
:In article <bv**********@canopus.cc.umanitoba.ca>,
: ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

:> ANSI C -defines- long as being large enough to hold a pointer,
:> and guarantees that if you convert a pointer to a long and back
:> again (with no arithmetic operations on the long) then the result
:> will point to the original object.

:That is news to me. And to many others. Including the guys who wrote the
:C Standard.

I'll cross-check my references when I next have an opportunity.


The standard says:
6.3.2.3 Pointers
(6) Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined. If the
result cannot be represented in the integer type, the behavior is
undefined. The result need not be in the range of values of any
integer type.

The "previously specified" refers to null pointers.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #34

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message news:<bv**********@canopus.cc.umanitoba.ca>...

ANSI C -defines- long as being large enough to hold a pointer,
and guarantees that if you convert a pointer to a long and back
again (with no arithmetic operations on the long) then the result
will point to the original object.


I don't believe it does. It allows pointers to be converted to
integers in implementation-defined ways. It's not clear to me
that it requires that a big enough integer exists (in C89 at
least) and I'd welcome chapter and verse if it does.

K&R2's Reference Manual says that converting a pointer to a
'big enough' integer and back again will give a pointer that
points to the original object. I can't see how to derive this
from the Standard, so chapter and verse would be welcome again
if it's there. The Standard does imply that this is the
preferred implementation.
Nov 14 '05 #35

P: n/a
J. J. Farrell wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message
news:<bv**********@canopus.cc.umanitoba.ca>...

ANSI C -defines- long as being large enough to hold a pointer,
and guarantees that if you convert a pointer to a long and back
again (with no arithmetic operations on the long) then the result
will point to the original object.


I don't believe it does.


You are right to be sceptical.

3.3.4 of (my draft copy of) the ANSI C Standard says: "A pointer may be
converted to an integral type. The size of integer required and the
result are implementation-defined. If the space provided is not long
enough, the behavior is undefined. An arbitrary integer may be
converted to a pointer. The result is implementation-defined."

No guarantees there about the original pointer being restored when you
convert it back.

The latest Standard says in 6.3.2.3:

"5 An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined, might not be
correctly aligned, might not point to an entity of the referenced type, and
might be a trap representation.56)

6 Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined. If the result
cannot be represented in the integer type, the behavior is undefined. The
result need not be in the range of values of any integer type."

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #36

P: n/a
In <5c**************************@posting.google.com > jj*@bcs.org.uk (J. J. Farrell) writes:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message news:<bv**********@canopus.cc.umanitoba.ca>...

ANSI C -defines- long as being large enough to hold a pointer,
and guarantees that if you convert a pointer to a long and back
again (with no arithmetic operations on the long) then the result
will point to the original object.


I don't believe it does. It allows pointers to be converted to
integers in implementation-defined ways. It's not clear to me
that it requires that a big enough integer exists (in C89 at
least) and I'd welcome chapter and verse if it does.


Neither standard requires the existence of such an integer type.

C99 provides the *optional* intptr_t and uintptr_t aliases to the
signed and unsigned flavours of an integer type that is large enough
for the purpose and on which conversions back and forth reproduce
the original value. The aliases are optional because the underlying
types need not exist.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #37

This discussion thread is closed

Replies have been disabled for this discussion.