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”.
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?
polr: The Microsoft article describes a way to go into the Registry to override the block.
I’ve offered a devil’s advocate argument here.
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.
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.
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.
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.
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.
@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.
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.
@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)” ?
“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.
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.
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.
@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.
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.
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…