Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

By the way, it is CVE-2012-0037, not -0337.  Sorry I didn't detect the original subject-line gaff 

Note that the official CVE reports are seriously unenlightening: 

The LibreOffice advisory is likely to simply scare the pants off of users since it is very 
circumspect and provides no information about how this matters to users and what they can do to 
avoid it (apart from upgrading): 

The Apache OpenOffice advisory is closer to what I consider the benchmark (advisory e-mails from 
Microsoft) in this area.  It does not presume remote code execution (at least, not in OO.o), and it 
describes mitigation more clearly: <>.  This 
can be done better.  I'd say not bad for a first effort though.

With regard to the lack of an OO.o 3.3.0 Linux patch from the Apache OpenOffice project, that was a 
mistake based on an incorrect assumption about how few people have installed OO.o from other than 
their Linux distributions.  There is an effort to address that underway now.  See this thread: 

 - Dennis

PS: Your conclusion that the exploit is unlikely is unsupportable.  

Whether an exploit actually manages to capture anything useful or embarrassing is another matter.  
It is also conceivable that a failed exploit may crash the application or at least result in 
mystery failures to open the document.

On the other hand, it is a bit like spam and phishing.  Since those are so easy to do, and 
inexpensive to distribute, the mischievous folks are willing to have a miniscule return rate, so 
long as there are any [;<).  (The easiest way to seed a wide distribution is by 
contributing/distributing a template file with the template built in.  Still a move-plot, but users 
need a way to satisfy themselves that there is no exploit.  There are so many faux download sites 
that it is a bit like walking down a road where all the street lights have been shot out.

This reminds me how the Iranian nuclear-material centrifuges were hacked by sending a trojan into 
the wild that apparently went global but was designed to fire with effect when it found itself on 
the correct computers.

Apparently it is the ease of crafting exploits that has the Apache categorize this 
as "Important" (but not "Critical").

-----Original Message-----
From: Tom Davies [] 
Sent: Friday, March 23, 2012 11:36
Subject: RE: [libreoffice-users] CVE-2012-0337

Hi :)
I think it would be good to post it here too.  

It's unusual for LibreOffice to suffer anything like it.  In almost any other program it wouldn't 
have even been reported as it's so trivial.  Just another patch for just another unlikely exploit.  
You basically have to be passing the document backwards and forwards   without changing formats 
with someone you think of as reasonably friendly but who is actually fairly evil and who has a 
fairly unusually high skill level and knowledge-base.  I think the "not changing formats" part of 
that is fairly unlikely at the moment.  Their skill level is an issue too.  Perhaps most people on 
this list could do it fairly easily but the average skill level here is far higher than the vast 
majority of office workers.  

With LO or other OpenSource programs such things are rare enough that they become big News stories. 
Regards from
Tom :)

[ ... ]

For unsubscribe instructions e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.