MS06-049 Causing Silent Data Corruption

Uncle Mike writes "It looks like there is a problem with the recently released MS06-049 / KB920958 patch. If you have compression activated on any folder, then the compressed data is at risk from corruption. New files that are close to a multiple of 4K in size will have their last 4,000 bytes or so overwritten with 0xDF. Although this problem has been reported to Microsoft, as yet there appears to have been no official announcement. "

Comments

How to avoid

[neonprimetime]

assuming you're using Windows

It has been confirmed that either turning off the compression attribute (disk space permitting) OR uninstalling KB920958 will prevent further loss of data.

Re:RAID

[phoenix.bam!]

RAID is not data backup. It is hardware backup. In this situation the RAID would just have multiple copies of the same file. Data backup is done with tape. Tape you can go back to and get an older version of the file, RAID offers no such solution.

Re:RAID

[khang]

wrong, RAID would just mirror the data corruption

Re:RAID

[Lehk228]

RAID will do absolutely nothing to protect data written incorrectly by the OS

RAID is not a backup

MS06-049 ...

[Anonymous Coward]

nicknamed (0x)DF aka Data F**ker

Re:How does something like this happen

[something_wicked_thi]

Oh, please.

MS bashing is fun and all, but do you have any idea how a kernel works? Anything can step on anything else. An off-by-one error in a kernel can be catastrophic to any number of things. This one does sound suspicious, but keep in mind that the code that is failing is probably only peripherally related to the code that was patched. They say they patched a buffer overflow. Maybe the buffer was already being overflowed by the compression code and patching it caused the compression to break. That might explain why it's the last 4000 bytes or so in a file that's almost a multiple of 4K.

The real question is why they didn't catch it in testing, especially with MS's extra-long patch process where they spend so much time testing (that is the current excuse for the months that pass between reports and patches, right?). Being "extra careful" does not save you from these types of bugs and being a programmer for as long as you have, you ought to know that being careful just doesn't cut it.

More background please...

[Chris Pimlott]

The summary blurb is rather cryptic. MS06-049 is a patch to... what? Just Windows 2000 or XP too? And this was a patch for some vulnerability, assumedly? Which?

After a bit of research, here's what should have been included: MS06-049 was an elevation of privledge issue discovered in the kernel of Windows 2000 SP4 only. The patch for the issue, KB920958, appears to have a bug resulting in corruption of compressed folder.

The title is misleading as well. MS06-649 is the issue and KB920958 is the patch; the patch is what's causing the corruption, not the original issue.

Compressed files, are you kidding me?!

[dave562]

This is a bit of a tangent, but a somewhat relevant one none the less. But first of all, bad Microsoft! You freaking imbilices (probably misspelled to show how dumb I am too.)

Is anyone out there seriously using disk compression in a production environment? Didn't anyone teach you guys that disk compression is a crutch and not a solution? For as long as I've been working with servers, all of my mentors have led me to believe that it is pretty much generally accepted practice not to use disk compression due to the potential for data corruption and the performance hit your servers take. If you need to compress files to save space, throw them onto some LTO or DLT media and pull them completely offline.

If you're working for a company that can't come up with more money for disk space, maybe you need to click on the Dice.com adds that are all over /. here.

Re:Compressed files, are you kidding me?!

[MrP-(at work)]

By default windows compresses all windowsupdate/service pack uninstall directories (i.e. c:\winnt\$NtUninstallKB123456$), it also compresses the dllcache directory (which keeps backups of system dlls and drivers)

Re:interesting

[X0563511]

Well, if you look closely you find that this patch is for Windows 2000 SP4 only, and all other versions of windows are not affected.

That does make a big difference, win2k is not MS' top priority.

Not that I condone their delay or lack of forsight, however.

Re:You can stop now

[joe_bruin]

I hate to burst your bubble, but you did not check the return code from printf. What if stdout is closed ...

Your program fails to take into account the case that printf(), fprintf(), and write() printed less characters than those that you provided. It further does not handle getting an EINTR on write().

RETURN VALUE
              On success, the number of bytes written are returned

Re:How does something like this happen

[abigor]

No, that's exactly where it gets handled. Using Linux as an example, different filesystems, compressed or not, are kernel modules accessed via the VFS. cramfs is a (rather lame) compressed filesystem built right into the kernel. Same with squashfs. Linux also has strong encryption (the CryptoApi) built right into the kernel for use with encrypted file systems.

Also, you may remember the file corruption bug from an older version of the 2.6 kernel - was it 2.6.10? It was much worse than this one from MS, which only affects compressed files on Windows 2000 SP4.

Re:Why even bother with compression anymore?

[tylernt]

I'm using snapshot-style rsync backups, so gzip is not an option.

http://www.mikerubel.org/computers/rsync_snapshots /

We can combine rsync and cp -al to create what appear to be multiple full backups of a filesystem without taking multiple disks' worth of space. Here's how, in a nutshell:

rm -rf backup.3
mv backup.2 backup.3
mv backup.1 backup.2
cp -al backup.0 backup.1
rsync -a --delete source_directory/ backup.0/

If the above commands are run once every day, then backup.0, backup.1, backup.2, and backup.3 will appear to each be a full backup of source_directory/ as it appeared today, yesterday, two days ago, and three days ago, respectively--complete, except that permissions and ownerships in old snapshots will get their most recent values. In reality, the extra storage will be equal to the current size of source_directory/ plus the total size of the changes over the last three days--exactly the same space that a full plus daily incremental backup with dump or tar would have taken.