> >What concerns me even more is this: under Windows I created a new
> >spreadsheet, inserted an image (http://blahblah), saved it and exited,
> >then ran it through strings, and saw some data from an email I
> sent a while
> >ago. WTF???
>> Nothing mysterious there, usual windows ole2 implementation is very
> strange in the junk it has in it, just grabs a fixed bit of memory
> doesn't init it all to 0 and always stores the full block faithfully.
> Thats just standard stuff, probably happens all the time under every os,
> contents of memory isn't cleared after being malloced so there can be all
> sorts of junk and previous bits of data in it,
There are a couple of points worth making, as there is scope
for confusion between OS and libc responsibilities here.
o Any _OS_ that doesn't clear memory when giving it to a
process is an insecure OS. However, malloc() and free()
live at the libc level (or whatever the C run-time is called
on your favourite platform).
o Any block returned by malloc() may contain crap that was in
any other block that was previously free()-ed, as well as
random internal libc data. If you don't like this, use
o However, blocks returned by malloc() should _never_ contain
data leftover from other processes (see first point).
o This issue where an Excel spreadsheet contains emails is
serious because Excel and the mail app live in different
processes. The OLE2 run-time libraries are per-process
DLLs. There isn't one central server process dealing with
structured storage (which could conceivably result in this
kind of unwanted data sharing).
o So how the fsck is the mail message data ending up in the
Excel process? Does OLE32.dll use some undocumented memory
allocation kernel API that doesn't clear memory? Eek!
Interestingly, this was a bug in the OLE2 libs with the original
release of Win95 and was fixed in Win 95 OSR2 (see MS KB
article Q139432). I could understand it happening in Win9x
as there is still quite a large amount of 16-bit code, which,
for backward-compatibility reasons, is shared among all
processes. However, IIRC, the 16-bit OLE2 libraries on Win9x
are implemented as thin wrappers (thunks) around the native
32-bit OLE2 implementation, rather than the other way around, so
it's possible that OLE2 internal data might get shared
accidentally between _16-bit_ apps, but 32-bit apps should
still be isolated.
So, if this issue has cropped up again, something has gone
badly wrong. Again...
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!