CERIAS - Center for Education and Research in Information Assurance and Security

Skip Navigation
CERIAS Logo
Purdue University - Discovery Park
Center for Education and Research in Information Assurance and Security

Think OpenOffice is the solution?  Think again.

Share:

[tags]viruses,OpenOffice,Word,Microsoft,Office,Powerpoint,Excel[/tags]
In my last post, I ranted about a government site making documents available only in Word.  A few people have said to me “Get over it—use OpenOffice instead of the Microsoft products.”  The problem is that those are potentially dangerous too—there is too much functionality (some of it may be undocumented, too) in Word (and Office) documents.

Now, we have a virus specific to OpenOffice.  We’ve had viruses that run in emulators, too.  Trying to be compatible with something fundamentally flawed is not a security solution.  That’s also my objection to virtualization as a “solution” to malware.

I don’t mean to be unduly pejorative, but as the saying goes, even if you put lipstick on a pig, it is still a pig.

Word and the other Office components are useful programs, but if MS really cared about security, they would include a transport encoding that didn’t include macros and potentially executable attachments—and encourage its use!  RTF is probably that encoding for text documents, but it is not obvious to the average user that it should be used instead of .doc format for exchanging files.  And what is there for Excel, Powerpoint, etc?

Comments

Posted by pat
on Wednesday, May 23, 2007 at 09:25 AM

lol open office lol

its for open source hippies and other communists !

Posted by Adam
on Wednesday, May 23, 2007 at 04:44 PM

Spaf,

Do you mean like the shift to the .docx and .docm formats, with the default being the no-macro .docx?  Or are you thinking more like the office trust center and related changes that allow you to open a macro-carrying document with macros disabled (the default from email).

Both shipped in Office 12. 

Speaking for myself, not MS.

Posted by Spaf
on Thursday, May 24, 2007 at 09:22 AM

More like .docx, assuming it doesn’t have some of the other vulnerabilities such as pointer corruption and buffer overflows.

The problems is that this is over a decade late, and won’t get retrofitted as the default for all the existing versions of Office out there.

And it doesn’t address problems with Excel and Powerpoint…

Posted by Ariel
on Thursday, May 24, 2007 at 10:10 AM

Spaf,

Would a solution be a rasterizing document format?  Is the problem the execution of the document or the possible extensions?

And what do you think of the format formerly known as PDF?

Ariel

Posted by Adam
on Thursday, May 24, 2007 at 04:55 PM

The same format change is in Excel and Powerpoint, both of which have ..x and ..m variants.  I don’t know about the other document formats, but I believe this was done for all macro-carrying Office formats.

Posted by Spaf
on Friday, May 25, 2007 at 06:58 AM

Rasterizing would give an image of the document, but that has downsides too—including size.

PDF has had one or two problems several years back, but appears to be a well-accepted and fairly stable format for expression of document contents to readers.  It doesn’t really support the reuse of material all that well, however.  But for most things that are posted or exchanged and are intended to be in final form, it’s a good solution.

Posted by Ed Finkler
on Friday, May 25, 2007 at 07:13 AM

I’m actually pretty iffy on PDF, at least with Adobe Acrobat Reader.  Reader had a disastrous hole in it a few months back that allowed for XSS attacks to be executed against PDFs hosted on a web site.  It was impossible to fix on the server side.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0045

One can embed an impressive amount of logic inside a PDF using Adobe’s Javascript API.  I’d be surprised if macro-virus style malware wasn’t possible.

Posted by Scott Yost
on Wednesday, May 30, 2007 at 01:51 PM

The MOICE converter can be used with the downlevel versions of Office to get most of the effect of the sanitized transport you describe above.

The converters run under a restricted process token to convert the old binary formats up to the XML formats, stripping macros and things like that on the way. I think it can also be deployed in an enterprise by changing the file associations using group policy.

details:
http://blogs.msdn.com/david_leblanc/archive/2007/05/08/new-file-converter-coming-soon.aspx

Posted by pierce
on Wednesday, September 5, 2007 at 06:23 AM

I don’t think that macros are the issue.  By definition, if you want to parse any given file format, you need to use a parser.

All parsers have weaknesses.  Some worse than others.  Reducing complexity helps, but is not a realistic solution in a world where everyone is competing to have the best feature set.

What would be nice is if these applications were less tolerant of malformed documents, exiting out at the first signs of anything sketchy.  I think this will be much easier to do with the new xml based document specifications.

Also decent access control would be nice, where you get an alert if the parser tries to descend into anything like a javascript parser etc.

Leave a comment

Commenting is not available in this section entry.