Last week I was sorting through several sets of Microsoft C 5.1 disks from 1988 (more about that later). While I was comparing the disk images to see whether the disks were the same or not, despite different labels and part numbers, I did a double take when I realized that a file with random e-mail fragments was, in fact, a MS C 5.1 disk:
nts to the beginning of an _iob structure within the _iob array. But that's not very likely. What usually happens is people passing in NULL or some random value. From davewe Wed Nov 11 11:10:28 1987 To: jeffrob stevesa Subject: stream validation Cc: barrymc billjo dougbo gregf Date: We
It’s not clear on which host OS the MS C 5.1 disks were created and how (copying files to a floppy vs. creating disk images on a hard disk). But it is certain that the software involved did not sanitize the buffers and random fragments of data stored in the host system’s memory ended up in the final sectors of numerous files.
The issue is that with random length files and fixed size (512 bytes) sectors, there is almost always some unused space in the last sector allocated for a file. All modern operating systems and software sanitize this storage, since not doing so is a potential security hazard. If sanitization isn’t performed, things like this can end up on distribution media shipped to customers:
and we're going to KILL HIM WITH HAMMERS. Hahahahahahahaha. And THEN we're going to ... From reedk Fri Feb 26 14:49:45 1988 To: gregf Subject: reminder Date: Fri Feb 26 15:40:54 1988 Mail-Flags: 0000 the dates and times on the release to kamber need to be 5.10 am etc. thx From erikl Sun Feb 28 23:30:46 1988 To: billta dougbo gregf mikeko timc Subject: Resignation Date: Sun Feb 28 23:26:25 1988 Mail-Flags: 0000 I am resigning from Microsoft effective 5:00 pm, Friday,
It is possible that disk buffers weren’t cleared before use, and it’s also possible that the host OS Microsoft used did not clear memory handed out to a new process (that would certainly be the case in DOS). In any modern OS, process B must not receive allocated memory that process A previously used without the memory being scrubbed, typically zeroed. Otherwise all sorts of sensitive information might accidentally leak through.
To: pauls Subject: Mouse Driver Update Cc: alisonc gregf reedk rossg Date: Wed Mar 2 11:51:31 1988 Where do we get the new version of the mouse driver? We are building our final disks for C 5.1 today!! Is this tested and stable?
Most of the fragments are not particularly enlightening or damaging, but perhaps slightly embarrassing as the one above.
ake it equally difficult to change the limit. Let's keep the run-time consistent. From rossg Fri Dec 18 11:54:51 1987 To: dos5 user5 Subject: Conversion to xenix386 - important Date: Fri Dec 18 12:50:50 1987 Mail-Flags: 0000 The following is a description of how we plan to do the
Mentions of other products are certainly interesting. Note the ‘dos5’ mail alias above, which was no doubt the internal OS/2 (at one point known as DOS 5) mailing list and Microsoft.
y new error codes to appropriate ERRNO values. Let's hope that IBM doesn't decided that they need new libs for IBM C/2 v1.0 (also known as IBM C 2.0) because of this... From stevesa Thu Oct 1 22:55:18 1987 To: boca5!scottr Subject: How spawnlp might set errno Cc: davewe gregf Date: Thu Oct 1 22:55:15 1987 Mail-Flags: 0000 | From boca5!scottr Thu Oct 1 08:49:13 1987 | To: microsoft
The above shows Micorosoft’s communication with IBM (in Boca Raton, FL). For the most part, the fragments are simply historical curiosities.
Mail-Flags: 0000 Here are three new PTMs: Component: FAPI Error: ABE Level: OS/2 v1.1, rev 4.67 (88-02-18) Environment: IBM PC/AT, DOS 3.3 Abstract: Family API DosOpen fails to open "PRN" Error: A bound program which opens the printer device using an "OpenFlag" of 041h and an "OpenMode" of 012h fails running in real mode but works in protected mode. Changing the OpenMode from 12h to 11h causes the open to succeed, but the 12h value should also work. Component: USHP Error: ABO Leve
The above is a bug report against the in-development OS/2 1.1, a build from February 1988, somewhat older than the revision 4.72 build from March 7, 1988 which was distributed with the MS OS/2 1.03 SDK.
Random memory fragments such as those listed here can be found on many IBM and Microsoft disks, but usually they contain bits of directories or executables, not plain text of e-mails.
It seems highly likely that others would have noticed these fragments on the MS C 5.1 disks in the 25+ years since its release. Or perhaps not?
This sort of data “leakage” was relatively common in arcade ROMs and game console cartridges of the mid to late 1980s. MS-DOS based EPROM programming software of the time apparently never did a memset() on their buffers.
I’ve never heard of it happening for PC software disks before this post though. I’m curious what their specific build process for gold masters was that allowed this sort of leakage.
I doubt any of that is from in-memory buffer corruption. It looks more like the problem of the simple DOS write protocol that only writes the bytes requested and ignores the rest of the cluster coupled with a Copy utility that grabs complete sectors without examination. So if the space had been used before, the remnants of the deleted file will exist after the end of the saved file. Some programs did attempt to pad the write but those tended to round up to the next 128 byte (if written for CP/M originally) or 512 bytes (DOS) not the potentially 32kB cluster of a late-80s hard drive. NT solved the problem many years later by wiping deleted space before reuse. Having a second write cycle does have a negative impact on disk performance.
I know this was a problem with other simple file systems on low end hardware like P-System or RT-11. I used to have a list on when various OSes implemented more secure wiping of slack space on files but I can’t find it. Conversely, Oracle has recommended REUSE of existing files to improve performance even though that means someone could read the logs of a previous installation (for a few hours until the new log overwrites everything).
I vaguely remember a program that put metadata after the listed end of the file in the slack space but counted on that data being copied with the file. Just plain crazy. Doing file writes and copies correctly would mean breaking applications that depended on DOS not paying attention to file contents. Was still an issue in 2004, see http://www.drdobbs.com/beware-of-file-slack-attacks/184405835
I know that in the early 1990s, Microsoft used a utility which took a bunch of files and turned them into a disk image with a boot sector, FATs, directories, etc. I don’t know if this is how the MS C 5.1 disks were created. My guess is that probably yes, and that the leaked information came from memory allocations where the OS reused previously occupied memory without sanitizing it (standard in DOS). But that is just guess.
I don’t see how this would apply to a 1.2MB disk with one sector per cluster (and 0 bytes free)?
Maybe the user who made the distribution disks was reading email prior to making disks.. waiting for the mouse drivers I suspect…
Now we need a utility to dump the unallocated space on a FAT filesystem and check all the disks…
Also I guess “gregf” was a low level guy?
I was too lazy to write a utility to dump the slack/unallocated space, but it shouldn’t be terribly hard. I have no idea who gregf was/is but I’m guessing most of the e-mails were sent within the Microsoft languages group (i.e. compiler people). I didn’t recognize any of the names but also didn’t try too hard.
And yes, this is why there is a big difference between a disk image and a file dump 🙂 It is too bad that some floppy image formats deliberately do not store unallocated sectors so gems like this can get lost (not in this case, since the data is within allocated though not fully utilized sectors). Then again at least for Microsoft stuff, someone probably still has the original disks with DOS/compilers/apps/whatever.
And now I’m wondering if some old CD mastering software also had similar “leakage”.
I have seen similar data retention problems on the previous generation cellulose based technology. This pre-dates floppy disks by some time but the problem is the same. The user forgets to erase his buffers before spilling new data into the previously used receptacle. It is inconsiderate and potentially dangerous.
Very cool find. Heartbleed, ’88 style
Pingback: Site Update | OS/2 Museum
Pingback: Weekendowa MEGA Lektura 2015-02-13 | Zaufana Trzecia Strona
AFAIK a very similar problem happened on VHS tapes. Sometimes tapes were reused and then sold or rented out. Usually it didn’t cause any serious problems but atleast in Sweden there were (IIRC) some cases where some childrens movie didn’t fill the tape and afterwards came the end of some porno movie… Ooops 🙂
On early Amiga “kickstart” disks (rom system software weren’t finalized when the first Amiga started to sell so that first model loaded a “rom image” from ram upon everey power-up) there were leftovers from some other useage of the disk. The disks cound hold 880KB but a “kickstart” image were only 256KB.
>Usually it didn’t cause any serious problems but atleast in Sweden there were (IIRC) some cases where some childrens movie didn’t fill the tape and afterwards came the end of some porno movie… Ooops
Ah, to live in the United States, where all our accidental VHS porn is from county sheriffs returning the wrong tapes to the video rental store… 😛
A little off-topic and necromancy – but amazing that Microsoft had some sort of e-mail + networking in ’88. Does someone know what e-mail system they used and with what kind of network?