• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

An Antic Disposition

  • Home
  • About
  • Archives
  • Writings
  • Links
You are here: Home / Office / Legacy format FUD

Legacy format FUD

2008/01/02 By Rob 17 Comments

From CyberTech Rambler (and Slashdot) comes the news that the Office 2003 Service Pack #3 disables (blocks) access to a number of legacy document formats. Details are in this MS support article. Formats so blocked include legacy Lotus 1-2-3 and Corel Quattro Pro formats. Why? According to the Microsoft support article, “By default, these file formats are blocked because they are less secure. They may pose a risk to you.”.

Interesting. Well, let’s look at the record. If we query the CERT vulnerability database for “WK1”, “WK3”, “WK4”, etc., how many reported vulnerabilities do we see? Zero. Nothing.

But search the same database for “XLS” and what do we see? Eleven reported vulnerabilities:

ID Date
Public
Name
VU#493185 01/09/2007 Microsoft Excel vulnerable to arbitrary code execution via malformed record
VU#176556 10/10/2006 Microsoft Office fails to properly parse malformed records
VU#807780 10/10/2006 Microsoft Office fails to properly parse malformed Smart Tags
VU#194944 03/07/2007 Microsoft Windows fails to properly handle malformed OLE documents
VU#234900 10/10/2006 Microsoft Office fails to properly parse malformed strings
VU#534276 10/10/2006 Microsoft Office fails to properly parse malformed chart records
VU#613740 02/02/2007 Microsoft Excel memory access vulnerability
VU#706668 10/10/2006 Microsoft Excel fails to properly process malformed DATETIME records
VU#252500 10/10/2006 Microsoft Excel fails to properly process malformed COLINFO records
VU#143292 07/03/2006 Microsoft Excel fails to properly process malformed STYLE records
VU#802324 06/16/2006 Microsoft Excel vulnerability

Hmm… I’m so glad they disabled access to the risky formats.

And what about the Data Interchange Format (DIF), the text based format for exchanging data between spreadsheets. As well as being text-based and easy to parse, DIF doesn’t allow any active code (scripts, macros) at all. Where is the security risk there, real or perceived? By what stretch of the imagination can Microsoft say, “…these file formats are blocked because they are less secure. They may pose a risk to you.”

Now it may be entirely possible that these old import filters in Excel are poorly written and poorly maintained and that Microsoft may be trying to reduce the overall security exposure of MS Office by ditching old code that is not strategic for them. But call it that. The MS Office code has the problem. Don’t malign the formats. Don’t make up some untenable story that DIF format is “less secure” and “may pose a risk for you”.

  • Tweet

Filed Under: Office

Reader Interactions

Comments

  1. PolR says

    2008/01/02 at 12:21 pm

    When I saw this story, I thought of archivists that have to support older documents in these formats. How are they going to read them now? Will they implement Open Office or a derivative?

    Reply
  2. Gary McGath says

    2008/01/02 at 4:27 pm

    polr: The Microsoft article describes a way to go into the Registry to override the block.

    Reply
  3. Gary McGath says

    2008/01/02 at 7:59 pm

    I’ve offered a devil’s advocate argument here.

    Reply
  4. Anonymous says

    2008/01/02 at 8:33 pm

    Considering how they sung exactly the opposite tune when we were discussing autospacelikeWord95 & co. I think that someone should mention this to those committees.

    Also, this will only help any competing products which still *can* read these formats.

    Reply
  5. Rob says

    2008/01/02 at 8:58 pm

    Interesting argument, Gary.

    However, no one can claim ignorance of the old 1-2-3 formats. They were published in book form years ago for all to read. WK1 in particular has been in use for almost 20 years. I can’t recall seeing a single security flaw related to WK1 files ever. So what basis does Microsoft have to malign that format by calling it dangerous. This is pure FUD.

    Now certainly, it is true that poorly written software can suffer from unchecked memcpy’s, overflowing string concatenations, and all the C/C++ bugs that will bash your stack and corrupt your heap. Poorly written code will always be risky from a security standpoint. As an example, look at the history of MS Office flaws related to the processing of DOC and XLS files. But these are application errors, not format errors. No one would suggest that Microsoft remove its XLS support. They just fix the bugs.

    It will be interesting to see if Microsoft issues a security bulletin or advisory on specific flaws in these legacy formats they are blocking, as is their normal practice when they discover a security flaw, or whether these features just disappear with SP3, accompanied by vague innuendo, but no specifics.

    Note that this isn’t the first time that Microsoft has FUD’ed on file format security. In Massachusetts, against ODF, they tried it as well, an attempt which caught the attention and rebuttal of security guru Bruce Schneier.

    In any case, we’ve been adding SmartSuite file format support to Lotus Symphony, seemingly at the same time Microsoft is removing their own Lotus file format support. This is great for us. I shouldn’t be complaining. We’re always glad to offer an upgrade path for former Office users.

    Reply
  6. Anonymous says

    2008/01/02 at 10:05 pm

    Nothing has been “removed” Rob, just turned off by default. It is easy enough to turn the support for old files formats back on should you need it. The KB article in the /. story explains how, and provides tools to do it for you if you want to use them.

    Reply
  7. Queen Elizabeth says

    2008/01/02 at 10:22 pm

    You leave out one important point, Rob: when Lotus 1-2-3 came out, security was not such an issue. PCs were generally standalone machines without Internet access, let alone the plethora of malware we have nowadays. Did the CERT database even exist in those days?

    One of the reasons that no file format -or- implementation bugs for WK1 and like have not been reported is that nobody has used those formats in years! When was the last time somebody e-mailed you a WK1 file?

    If you started looking, I’m sure you’d find bugs aplenty in 1-2-3 1.0 (as well as Multiplan 1.0 and VisiCalc.) But what’s the point?

    I think it’s good if Microsoft is removing buggy old code–after all, the only people creating new WK1 files these days would be virus authors in search of an exploit.

    Reply
  8. Rob says

    2008/01/02 at 10:40 pm

    You are playing with words. The fraction of end users who read Microsoft’s KB articles and have a copy of the “Office 2003 Service Pack 3 Administrative Template (ADM), OPAs, and Explain Text” or know how to edit the Windows registry is, when rounded off to two significant digits, 0.0%.

    If a feature was working on the day you bought Office 2003, and then the feature no longer works a few years later, then it has been removed. That is what the end user sees. A feature that has never been the source of any reported security exploit has been removed.

    Note also that these formats, the WK1, WK3, WK4, etc. 1-2-3 formats were also removed from Office 2007. There is no way of re-enabling them there.

    One another point, someone sent me an email pointing out that only the old legacy Lotus 1-2-3 formats have their support removed. The most recent format, used by 1-2-3 for Windows, the .123 format, is not mentioned in the Microsoft KB article. Well… I hate to give you the bad news, but Microsoft — in the past 15 years — never got around to adding support for the .123 format to Excel. That is why they cannot remove it. So in effect, Excel is now removing every bit of 1-2-3 file format support they ever had.

    Reply
  9. Rob says

    2008/01/02 at 10:55 pm

    @Queen, When were you born? Before the internet was some of the worst days of viruses and malware. I saw far more trouble back then from viruses passed from floppy to floppy than I see today from the internet. Remember, just because were weren’t all networked didn’t mean that we didn’t exchange data. We just did it in different ways. And we didn’t have antivirus or modern operating systems to protect us, at least not on PC’s.

    In any case, we’re not talking about 1-2-3 code, we’re talking about Excel code. Is it right for Microsoft to sell a product — Office 2003 — with a certain set of features, and a stated support period, and then to remove these features? Remember Mainstream Support for Office 2003 runs until January 13, 2009. This includes free security updates. So if there are any defects in Excel’s file support, they should be fixed.

    Reply
  10. Anonymous says

    2008/01/02 at 10:58 pm

    You have spent too long with IBM Rob, you really don’t need a big iron company mentality to help you manage a PC, the common man (or woman) does understand computing these days and can generally find their own way around their own system… not every time, but a lot more than you give credit to.

    This isn’t the 1960s anymore.

    Reply
  11. Rob says

    2008/01/02 at 11:56 pm

    @anonymous, I don’t have that “big iron” mentality. Remember I came to IBM from Lotus. I’ve never even seen a mainframe.

    In any case, registry editing is not an end user task. The Microsoft KB has a big scary disclaimer on these instructions, “Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.”

    Does this sound like a task you would recommend to the “common man (or woman)” ?

    Reply
  12. Alphadog says

    2008/01/03 at 11:54 am

    “Where is the security risk there, real or perceived?”

    If they [file translators/converters] are being poorly coded and/or maintained by MS, then they could be subject to common attacks like buffer overflows.

    While your main point that MS’ ability to take away a user’s choice is noted, I think both MS and you are doing a disservice to users: MS for pinning the removal on security, and you for saying that there’s no security risk in files that contain no embedded executables or scripts.

    Reply
  13. Gary McGath says

    2008/01/03 at 2:27 pm

    Alphadog wrote: “If they [file translators/converters] are being poorly coded and/or maintained by MS, then they could be subject to common attacks like buffer overflows.”

    Yes, but this is a flaw in Microsoft’s software if that’s the case. Microsoft is claiming that the flaw is in the formats themselves and not in their own software.

    In the post I linked to earlier, I speculated that MS might be dependent on third-party binaries for support of undocumented formats in some cases, in which case the difference between the software and the format specification blurs. But that’s a different case from software maintained by MS.

    Reply
  14. Anonymous says

    2008/01/03 at 3:33 pm

    The old Lotus 1-2-3 and Quattro Pro file formats pose the same security concerns as .DIF formats – none. .WK? files could contain \0 macros that could call /S or {system} statements that could run destructive or other malicious outside programs, but Excel HAS NEVER been able to process such macro calls in .WK? files.

    Similarly, Excel has never been able to evaluate any formulas in such files that call add-in @-functions, so potentially malicious formulas are also a nonissue.

    That leaves the same vulnerability as .DIF files – buffer overflows.

    FWIW, 1-2-3’s .123 file format was much, much less safe – Lotus provided no means to disable event handlers, so malicious Calculate event handlers would ALWAYS run on file open. However, Excel NEVER supported .123 files, so not an issue.

    Reply
  15. Rob says

    2008/01/03 at 3:58 pm

    @anonymous, I think you almost have it. But the autoexecute is an application flaw, if it cannot be disabled, not a file format flaw.

    But this is an interesting topic for discussion, document format security. Scripts/macros are not per se bad unless they are encoded in such a way that the application has no way of telling they they exist. If they are clearly delineated in the format then the application can, as a matter of policy, decide whether or not to execute them.

    The more easily they are indicated in the format, the easier it will be for things like antivirus scanners to detect and check them.

    Another lurking danger is binary blobs that are not interpreted by the application, but are passed on to other operating system modules to interpret. That was what made that flaw in the Windows Metafile (WMF) format so dangerous a few years ago.

    Reply
  16. another anonymous says

    2008/01/04 at 1:25 am

    If maliciously formed WMF files could be a problem, they might be a problem when embedded in .WK4 files. That is, .WK4 files can carry a lot of OLE junk that could cause problems. Of course, that’s been true since 1993, so it’s odd that MSFT is only now addressing the problem.

    However, the older 1-2-3 file formats, .WKS, .WK1 and .WK3, couldn’t contain embedded object, just cells containing formulas or constants, range names and macros, and as another commentator pointed out, Excel never was able to run external processes initiated from startup macros in any of the 1-2-3 file types.

    So .WK4 files may be problematic, but .WKS, .WK1 and .WK3 aren’t.

    MSFT chose to drop support for them in Excel 2007, and they seem to be backfilling deprecation in Excel 2003.

    Reply
  17. Victor says

    2008/01/05 at 11:17 am

    If you want to talk about support for legacy formats then how about support for Microsoft Word’s .DOC format ?

    Try to open this document in MS Office and see how well it’ll go. So much for backward compatibility…

    P.S. This file refers to style file (bundled in this zip) and is actually a sample file from Microsoft Word still downloadable from Microsoft’s site…

    Reply

Leave a Reply Cancel reply

Primary Sidebar

Copyright © 2006-2023 Rob Weir · Site Policies