Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

MS06-049 Causing Silent Data Corruption

Posted by Hemos on Mon Sep 11, 2006 09:30 AM
from the oh-who-wants-encryption-anyway dept.
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. "
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • interesting (Score:5, Insightful)

    by Intangion (816356) on Monday September 11 2006, @09:33AM (#16080780) Homepage
    its interesting how when they make a patch that corrupts your data you dont hear anything from them.. but when someone makes a program to allow fair use by opening DRM on their movies they come up with a CRITICAL patch within ours to prevent it. i think that speaks to their priorities, protecting their drm IMPORTANT protecting your data hmm.. not so important
    • by Colin Smith (2679) on Monday September 11 2006, @10:05AM (#16081036)
      What're your customers going to do?

       
      • When you have a monopoly what're your customers going to do?"

        Well I believe I'll invest in a second-party operating system!
      • by Tackhead (54550) on Monday September 11 2006, @10:28AM (#16081260)
        > When you have a monopoly
        >
        > What're your customers going to do?

        The guy at the keyboard of a Windows Vista box, using Microsoft Office at work, and Windows Media Player at home is not the customer, he is the product. The customers are Dell, AOL, media licensing conglomerates, and so on.

        • by theCoder (23772) on Monday September 11 2006, @11:17AM (#16081686) Homepage Journal
          That may be accurate for televion broadcasts, but it isn't so for Microsoft. Customers are people who pay for services. AOL and the media companies aren't paying MS anything, other than licensing fees for the services they use from Microsoft (i.e., their Windows PCs). Microsoft is paid by the guy at the keyboard of the Windows box (or his employer).

          Microsoft may be able to leverage all those customers into a product for another customer (such as advertising or licensing DRM solutions), just like the movie theater leverages their movie watching customers into a product for advertising. Until Windows is free (as in beer), the guy using Windows is a still a customer.
    • maybe one patch was just easier to write.

      --
      Carnage Blender [carnageblender.com]: Meet interesting people. Kill them.
    • Re:interesting (Score:4, Informative)

      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: (Score:3, Insightful)

        Have you read the EULA? Well, neither have I actually, but you don't have to be a partiualrly educated guesser to know that there is a provision in the EULA regarding the loss or corruption of data. You agree to endemnify Microsoft against any such loss. Further, they make no guarantee of suitability of the OS for any particular purpose and make no claim that the product is reliable in any way.

        You know, if I were to create a series of advertisements, I would make it similar to the "Truth" campaign agains
        • by deadlinegrunt (520160) on Monday September 11 2006, @11:09AM (#16081616) Homepage Journal
          "...Have you read the EULA? Well, neither have I actually..."

          Are you this person [amazon.com] by chance?
        • As the late Steve Irwin would say: "CRIKEY!".
          You're right, I should've known that venomous EULA would turn right back and bite me (and all Microsoft customers) in the rear.

          "Satisfaction Guaranteed!"*



          * The term "Satisfaction" and "Guaranteed" are used only for illustration purpouses in a figurative, subliminal manner.
          Enlarged to show texture. Serving suggestion.
          As a matter of fact, no satisfaction guaranteed whatsoever, by any means.
          Reading the words "satisfaction" and "guaranteed" above certifies
  • by creimer (824291) on Monday September 11 2006, @09:35AM (#16080791) Homepage
    If data is being silently corrupted, is there a problem if no one can hear it? That could explain Microsoft's silence.
  • How to avoid (Score:5, Informative)

    by neonprimetime (528653) on Monday September 11 2006, @09:35AM (#16080793)
    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.
  • RAID (Score:3, Funny)

    by Karma Farmer (595141) on Monday September 11 2006, @09:42AM (#16080846)
    As is often pointed out on slashdot, this is why it's so important to have a good backup plan. Like most slashdotters, I recommend RAID.
    • Re: (Score:3, Informative)

      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: (Score:3, Informative)

      wrong, RAID would just mirror the data corruption
    • Re: (Score:2, Informative)

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

      RAID is not a backup
    • Good troll.
    • Re: (Score:3, Insightful)

      I can't believe there were > 0 people who replied to Karma Farmer's comment thinking it was anything but an attempt at humour/troll, much less that any such poster would get their manties in a knot over it either.

  • "close to a multiple of 4K in size"

    How close is close? Is 162k close to 164k? Sounds like it is to me. From the examples in the discussion cited, it seems that anything over 4k is at risk, not just things 'near' a 4k boundary.

    I would even hazzard to guess that the size matters not at all, but rather the contents of the files. If the contents match a certain pattern, the compression goes awry and adds the garbage to the end. (Accidentally overwriting the real data.)
  • by robpoe (578975) on Monday September 11 2006, @09:43AM (#16080863)
    Well, it's interesting that 0xDF0xDF0xDF0xDF0xDF0xDF0xDF0xDF0xDF0xDF0xDF0xDF0x DF0xDF0xDF0xDF0xDF0xDF0xDF
      • I agree, some other people have meßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß ß ßßßßßßßßßßßßßßßßßßßß

        Oh, that explains it: it's a beta patch.
        • Re: (Score:3, Funny)

          I agree, some other people have meßßßß . . .

          Oh, that explains it: it's a beta patch.

          ß / 0xDF is &szlig ; or Esset. So the article is incorrect, the last bytes are overwritten with random data in the form of white noise. "ßßßßßßßßßßßß" is pronounced "ssssssssssssssssssssssssss". OMFG!11! SNAKES ON A PLATTER!

  • Strange (Score:3, Funny)

    by A beautiful mind (821714) on Monday September 11 2006, @09:51AM (#16080924)
    I've never heard Windows called MS06-049 before...
  • by Chris Pimlott (16212) on Monday September 11 2006, @09:58AM (#16080977)
    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 [microsoft.com] was an elevation of privledge issue discovered in the kernel of Windows 2000 SP4 only. The patch for the issue, KB920958 [microsoft.com], 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.
  • by Anonymous Coward on Monday September 11 2006, @10:05AM (#16081028)
    Those files were important! Sheißßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
  • by dave562 (969951) on Monday September 11 2006, @11:25AM (#16081751) Journal
    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: (Score:3, Informative)

      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)
    • Well, you assume that whoever made the MS06-049 patch actually took the time to understand the code he was patching and/or contacted the person who origionally wrote the code in question.
    • by avalys (221114) on Monday September 11 2006, @09:48AM (#16080901)
      If you really have been programming for a long time, you must only be writing very simple programs if you've never had something like this happen, and you think that being "extra careful" is all you need to do to avoid it. What type of programmer does this? Every type of programmer - it's unavoidable.

      The programmer is not to blame here. The real question you should be asking is "What type of QA department fails to catch a bug like this?"
      • I agree and disagree with you. As long as the programmer properly unit tested his/her work, then you can shift blame to QA. I have seen developers not properly unit test their code too many times, relying on the QA department to do their work for them. But yes, unless it happens in very rare circumstances (is this the case?) someone should have caught this in testing somewhere... but not necessarily just QA.

        IANAQAT (I am not a QA tester).

          • Re: (Score:3, Interesting)

            Baloney. Don't blame the testers if they can't find all the bugs written by a poor programmer. It's the [good] programmer's job to test their own code first, as they have the most intimate knowledge of all the ways it could fail.
      • Re: (Score:3, Insightful)

        Some software bugs manifest in rare cases, and can only be found by code inspection or luck. Unless you work with languages that allow 100% guaranteed mathematical proofs of correctness.
    • 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 migh
        • Why?

          File system is handled by a kernel. File system compresses files before writing them to the disk, respectively decompresses them during read operations. Therefore, the compression is handled in kernel. Where would you handle it?

          Data compression is not like black magic. As the matter of fact, the most data compression algorithms out there are mind boggingly simple and very well understood.

          Of course you could move the file system into the user space, but that would introduce some bad performance
        • Re: (Score:3, Informative)

          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
    • by CosmeticLobotamy (155360) on Monday September 11 2006, @09:50AM (#16080923)
      What type of programmer puts such possibilities or leaks in a program?

      Every programmer that's ever worked on something longer than 6 or 7 lines of code? Except you, of course. I've been in the bathroom after you and am always impressed by the way it smells just like roses.
    • ...similar to their (in)famous debug version of the new operator (IIRC generates guard bytes set to 0xCDCDCDCD).

      While they are doubtlessly not releasing images with debug info, they might be using an overriden new operator that does something similar (for a variety of reasons).

      It is hard to say, but this type of error - while *not* acceptable, *is* understandable,
    • My pure guess based on /. comments: How can this happen? Loop counting error. Probably from integer division of the file size/ 4K chunks. Allocator did it right, loop missed the last chunk. Very common. Typically a novice error. But can blindside even experienced ones. QA should have nailed it.
    • by Rashkae (59673) on Monday September 11 2006, @11:12AM (#16081649) Homepage
      Maybe you should ask Linus... I seem to remember a released stable kernel that neglected to sync file systems before shutting down.....

      I love Linux, hate Windows, but point it, sh!t happens.
      • by 0xABADC0DA (867955) on Monday September 11 2006, @11:31AM (#16081795)
        I hate to burst your bubble, but you did not check the return code from printf. What if stdout is closed, as in "./a.out >&-"?

        Original troll never writes any bugs, so his hello world is more like this:
        int main(int czArgCount, LPSZ *lpszArgv[]) {
            if (-1 == printf("Hello world!\n")) {
                if (errno == EBADF) {
                    if (-1 == fprintf(stderr, "Error stdout closed!\n")) {
                        int fdTty = open("/dev/tty", O_WRONLY, 0666);
                        if (fdTty != -1)
                            write(fdTty, "Hey dumbass dont close my streams\n", 34);
                    }
                }
                exit(1);
            }
            exit(0);
        }
        • Re: (Score:3, Informative)

          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: (Score:3, Insightful)

        Hopefully that's a joke. Pretty much nobody would put music on a compressed drive, as nearly ALL of the music formats in common use today are compressed. Rather heavily. Those music formats that aren't don't compress very well anyway.

        Additionally, the thought that MS would release a patch that intentionally corrupts data is unthinkable, for ANY corporation. The civil (and possibly criminal, who knows) liabilities would be ENORMOUS.
    • I use compression on folders in XP Pro. and Home SP2. I have not seen this problem on my systems at home and work. I always get the newest patches on their first release dates. I even defragged (PerfectDisk v6.0 with its patches) over the weekend. I haven't seen anything odd. I am usiDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFD FDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDF

      You might want to double check. ;)
        • Re: (Score:3, Insightful)

          You don't just make /var/log a compressed filesystem...

          I'm no MS fanboy, but... suppose the OS in question had some sort of directory-compression scheme that had a seven-year track record of impressive stability and effectiveness? Why not use it?

          Disk compression earned a terrible rep back in the 90s, when DOS/Windows and Windows 95 themselves were so unstable there was no chance that it could work properly. But MS finally got it right when they swiped tech from Stacker and included directory compression in
        • Re: (Score:3, Informative)

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

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

          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