Home > Standards Blog

Advanced Search 

Welcome to ConsortiumInfo.org
Tuesday, February 09 2010 @ 01:21 PM EST

Monocultures and Document formats: Dan's Bomb Goes Off

OpenDocument and OOXML

Dan Geer is an extremely well respected security expert.  When he worries about something, people listen.

One of the things he has worried - and warned - about is the danger represented by IT "monocultures" - the situation that arises when everyone uses the same software, for example, and therefore everyone shares the same vulnerability to a computer virus or other security threat. 

Just as the word "virus" has been borrowed from biology and provides an apt and vivid descriptor for its IT analogue, so also does the word monoculture function: think of the consequences of Irish potato blight, or of the wiping out of the American Chestnut tree, which once numbered in the billions in the forests of the American East and is almost extinct as a mature species.

Well, last November, Dan wrote a perspective piece for CNETnews.com, called Massachusetts Assaults Monoculture.  In that article, he wrote:

As a matter of logic alone: If you care about the security of the commonwealth, then you care about the risk of a computing monoculture. If you care about the risk of a computing monoculture, then you care about barriers to diversification. If you care about barriers to diversification, then you care about user-level lock-in. And if you care about user-level lock-in, then you must break the proprietary format stranglehold on the commonwealth. Until that is done, the user-level lock-in will preclude diversification and the monoculture bomb keeps ticking.

As it happens, Dan's bomb went off a few days ago, with the breakout of the "Backdoor.Ginwui" virus, a malicious bit of code that Symantec introduced in an alert as follows: 

It has been reported that Backdoor.Ginwui may be dropped by a malicious Word document exploiting an undocumented vulnerability in Microsoft Word. This malicious Word document is currently detected as Trojan.Mdropper.H.

The fact that Dan's expectation came true can hardly be a source of surprise.  Indeed, the only curious aspect of the fulfilment of his prediction is that it took as long as it did to occur.

The reason, of course, is that hackers like targets that offer the most visible and dramatic results - and the bigger the better.  If that target is unpopular (such as Microsoft), then again, so much the better.  Thus it is that the more successful the software product, the more attractive it becomes.  That's no criticism of Microsoft, or of any other vendor, but one of the regrettable costs of success.

Still, from the end-user point of view, it is an added burden on the value of the product in question.  After all, it's one thing to have a target painted on your back and reap huge profits as a cost of doing business, and quite another to pay a premium price for a dominant product, and share the same risk without offsetting compensation.

It's also not a surprise that something as prosaic as a Word document should become the innocent carrier of a bit of malicious code.  After all, stringent security policies (such as those my firm employs) already block jpegs, zip files and other vehicles known for problem code.  But no one's policies automatically block all Word and Excell files, since those are what - for now at least - most people create, send and read (they do, of course, scan them for known viruses).  This therefore elevates such files not only to the level of ideal vectors, but grants them the status of attractive challenges as well, capable of showcasing the chops of whatever hacker can succeed in employing them to pull off a high-profile assault.

All of which, as regular readers of this blog might assume, leads me to a conclusion that has something to do with ODF - a standard that is already supported by four major products, two of the proprietary persuasion (Sun's StarOffice and IBM's Workplace Managed Client) and two of the  open source (OpenOffice and K Office) variety.

The risk profile between a monoculture and a diverse IT culture such as this is mathematically clear.  By definition, even if ODF compliant products as a group were someday to trade marketplace shares with Microsoft Office, no individual user of any ODF compliant product would share the same degree of risk that every Office user has today, by reason of the fact that she would inhabit an IT culture with a much richer genetic pool.  And no virus is likely to operate at the level of standardization at which these disparate products exist.  As a result, just as a species with a diverse gene pool is likely to be able to withstand the assault of a new disease in far better form than a species of clones, so also would an IT environment based on multiple instantiations of ODF be more resilient than a monoculture of Office users, only more so.

Why more so?  Because in nature, a virus isn't personal.  No malign intelligence creates a natural virus to attack a specific target.  But in the world of hackers, the opposite is the case.

The moral of the Dan's story, as well as the current reality of the Word Backdoor Ginwui virus is therefore clear:  in IT diversity there is safety.

For further blog entries on ODF, click here

subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff's)

 

Monocultures and Document formats: Dan's Bomb Goes Off | 1,298 comments | Create New Account
The following comments are owned by whomever posted them. This site is not responsible for what they say.
Monocultures and Document formats: Dan's Bomb Goes Off
Authored by: Anonymous on Wednesday, May 24 2006 @ 04:45 AM EDT
<p>No one blocks Word/Excel documents?  I'm sorry?  What  security planet are you from?  Are memories really so short?  Macro viruses  have been around as long  as there have been word processors and email. Most sensible people do not accept any kind of Office document through email, in the same way as all other Microsoft files are blocked.</p>
<p>Why? Because they can all contain executable content. This really is not new. </p>
<p>Puleease!</p>

Clarification on blocking
Authored by: Andy Updegrove on Wednesday, May 24 2006 @ 06:32 AM EDT

What I said was that no one automatically _blocks_ all Word and Excell files - but of course everyone scans them.  Problem is, that only catches known viruses, and your spam software still has to be moment by moment up to date.  If we blocked all attached Word files (we're a law firm, and get hundreds of them a day), then we might as well shut down business, because that's how our clients communicate with us today. 

On the other hand, other types of files, such as jpegs, aren't sent to us often by clients, and they're much more likely to carry viruses - known and unknown.  So we don't allow them at all.  If someone gets an email with a zip file attached (not as likely to be dangerous, but still sometimes a problem) or a jpeg that looks real, we have to send it to one of our IT administrators, who checks it out.  If it's legit and clean, he opens it and sends it through.

I've made a change to the text of the blog entry to clarify this.

The point is, that if there were more office suites out there, each would have fewer viruses.  Some of those products might also compete on having superior security features and fewer flaws.  And the open source ones might attract fewer hackers just on principle.

 

Monocultures and Document formats: Dan's Bomb Goes Off
Authored by: Anonymous on Wednesday, May 24 2006 @ 07:35 AM EDT
Functionality is important too. If other office products come out (StarOffice, IBM Workplace & Openoffice are really using the same code to do ODF) there will be minor incompatabilties and quirks in each app.
Monocultures and Document formats: Dan's Bomb Goes Off
Authored by: Anonymous on Wednesday, May 24 2006 @ 09:29 AM EDT
Well, I almost go for it. But not quite. If ODF, or any standard, includes the ability to correctly and legally (by the standard) encode viruses then EVERY complying implementation, irrespective of source of the implementation, is vulnerable. I think that it must first be established that the standard offers, in and of itself, no opportunity to store and propogate a virus.

In reality, if Microsoft defined their macros such that they could only alter the document and nothing beyond the document, there would be no macro viruses. The fault lies in the definition of the storage format, the very thing that they are trying to standardize. If they succeed, viruses will forever have a home in a standards based document format. Anyone that implements to the standard will have to write the vulnerabilities into their code.