[ILUG] [Fwd: Sun StarOffice documents that "phone home" and other interestingproblems]

[Kenn Humborg]

> >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
   calloc().

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

Later,
Kenn