Security risks using data saves that include pointers ?

[Jose]

Probably a stupid question as on the Amiga you don't have much concerns (or uses) for security, but in general is there any big security risk if I include a dump of the memory location some pointer points to? This is used to signal if the next batch of data in the file is the data the pointer points to or not (if the ptr is NULL).
The only risk I see is that someone could use that to get the a memory location on the program, but then again that location contains only data, stuff exploiting buffer overrunns probably doesn't need to know where the data is anyway, they just flood the buffer to see the results...
What's your opinions on this ?

:pint:

[Jose]

Edited 2 setences, one that was wron the other to make it more clear....

[Piru]

Well, assuming you're using a system with secure memory, it also has secure file access permissions.

Also, even if someone else would gain knowlege of the memory addresses used, those adresses are only valid inside the current incarnation of the said application itself (yes, each process has it's own address space). Even if you get the logical address to the memory, you don't get the physical one, so it's impossible to access it from the outside.

So just pointers themselves are pretty much always harmless.

The above on systems such as bsd, linux, windows etc. On Amiga the system is exposed, so I doubt if leaking any pointer does any more harm anyway. Obviously this doesn't mean you should write passwords plaintext, or not wipe out plaintext passwords after reading/decoding them into memory.

[Louis Dias]

just a quick question...

Why would you save the memory location of data if the next time you launch your program, the data could be stored somewhere else in memory?

Wouldn't you just save the data?

[Karlos]

There is absolutely no reason to ever save a pointer on any normal system. The value it has is meaningless outside the particular instance the application was run.

The other point is that disk IO is almost always the determining factor in loading / saving files. Therefore there is no real performance gain in dumping a chunk of memory as binary data compared to finding a rational way of formatting the data for storage and doing that.

What I mean is, don't just dump the memory image of a structure, define a function that can serialize that structure to a file and have the equivalent function to unserialize it. More than likely not every field is needed.

If you have a lot of structures that reference each other, you can iterate the collection of structures you are to save, assign id values to each one (making it the first bit of data written for each structure definition) and replace pointers with id values of the objects the point to during serialization.

For completeness, you could even build a structure that contains record pairs of the structure id versus offset into the file and store that too. This gives you a complete map fron which you can totally reconstitute the data on loading, even if the objects all end up at different addresses, they will still correctly point to each other when you turn the id values back into pointers (which you do after loading them all, remembering where you allocated each one).

[Piru]

There is absolutely no reason to ever save a pointer on any normal system.

I think Jose is well aware of that. ;-)

[Karlos]

I'm sure he is, but dumping the data as opposed to structuring it for saving is surely just laziness.

Of course, if it's just a whole bunch of binary data, who would know which value in there was a pointer in the first place?

[Jose]

Hey 8-)
@Piru
More or less what I thought. I ended up not doing it though, as after trying it I discovered it would imply changes that wouldn't make the current algorithms I'm using faster.

@Karlos
Most of what you describe is more or less done  :-) Still need to finish some parts and test/correct bugs though..

"versus offset into the file"
That screws up alignment a bit and is a problem I still don't know ver well how to solve. If you compile it with a different compiler or with different settings that alter the alignment it will make the resulting file format different.

"..as opposed to structuring it for saving is surely just laziness."
Someone called me ? :-D I end up rewriting and tweeking stuff sooner or later though, honestly.

"Of course, if it's just a whole bunch of binary data, who would know which value in there was a pointer in the first place?"
Because the loader uses that same data block descriptions of the saver. So if it's loading a part of a block that's described as a pointer to something it needs to know if the pointer actually pointed to something or not. If it did it's non NULL (and hence I could just dump the pointer for speed), and the data it points to follows.
That the use:) But I ended up just put 1 or 0 values in there.

[Jose]

"That screws up alignment a bit and is a problem I still don't know ver well how to solve."

Without making the descriptions huge that is... They're mostly describing data blocks right now.