The odd saga of CVE-2012-5639 [LWN.net]

By Jake Edge
January 10, 2024

A new release for any project with a fix for a 12-year old CVE is going to stand out pretty obviously; a recent release has a fix of that nature, but the trail of CVE-2012-5639 is rather elusive. The Apache OpenOffice project made its 4.1.15 release with fixes for four CVEs, including one for CVE-2012-5639 ("Loading internal / external resources without warning"), on December 22. But nearly everything about that CVE seems rather murky, and it is difficult to get a clear picture of what, exactly, was done in OpenOffice to address the problem.

There is also another project involved, of course, since LibreOffice is descended from the same code base as OpenOffice. When the issue was first raised, back in 2012, Timo Warns was unsure if the problem of "remote file inclusion by office applications should be considered security-relevant". He noted that OpenOffice and LibreOffice would both automatically include remote content that was referred to in a document; Microsoft Word did so as well. User expectations are not being met:

Users are aware that web browsers may access remote content even when opening local files. I don't think users are aware that office application may do the same. An 'offline mode' for office applications that is enabled by default could meet user expectations.

Kurt Seifried tried to find a way to disable that functionality in LibreOffice; Warns said that it could not be disabled and Daniel Kahn Gillmor added some further information about the problem. Given that, Seifried assigned the CVE number and opened a Red Hat bug for it.

Tracking bugs for Fedora were opened for LibreOffice and OpenOffice as well; all of the bugs were eventually closed, but not because the problem had been fixed. The OpenOffice bug report was not needed, since that package had not been shipped for several Fedora versions at that point; and the LibreOffice tracking bug was automatically closed when Fedora 17 (the release the bug was filed for) reached its end-of-life in August 2013. Meanwhile, the main bug was closed in October 2021 as "errata", which is meant to indicate it has been fixed in a release, but there is no indication in the bug or its history about the resolution. A comment from Caolan McNamara when the bug was filed seems to indicate that it will be a difficult problem to address, but that's it.

A bug was filed for LibreOffice at the same time as the Red Hat bugs, but it was closed as "invalid" nearly a year later, with a comment from Joel Madero indicating that it is not really a bug, much less a security bug. The bug report was, instead, a feature request, he said, which should not be considered a vulnerability. There is also, apparently, a bug report for OpenOffice that had its status changed to "security" in October 2020, which means that it can only be seen by project members. It is not at all clear what precipitated that change at that time.

Tracking entries for the CVE for Debian and Ubuntu do not shine much light either. The Ubuntu entry was published in December 2019, while the Debian one has no date on it. Both refer to a blog post that describes a rudimentary "stealth mode" feature of LibreOffice 4.2; it provides a setting to: "Block any links from documents not among the trusted locations". Given that it is an opt-in feature, it may not completely address the concern leading to the CVE, but it does at least give users and administrators a way to prevent loading external content.

While the stealth mode feature has presumably gotten better since that release in 2014, it is still not enabled by default in the LibreOffice 7.2 installed on my system. There have been several CVEs (e.g. CVE-2020-12802) filed for content types that were not actually blocked by stealth mode, but those have been fixed. The feature set listed in the release notes for OpenOffice 4.1.15, which addresses the CVE, make no mention of a stealth mode, nor anything related, seemingly. The fixed bug list is also lacking in anything relevant.

OpenOffice is an open-source project, of course, so we can look at the code in the project's GitHub repository. However, the list of commits between the 4.1.14 and 4.1.15 releases is also not particularly enlightening. None of the commit messages refer to "external content", the CVE number, bug number, or anything else relevant. It is all rather odd.

One would guess that buried somewhere in that list of 143 commits for the most recent release is the change that addresses the CVE. But the project has not made it easy to figure out what the change is, what it does, how it works, or much of anything else. The locked bug entry is presumably just an oversight, but a fix for a CVE of this nature would seem to require at least a bit more information about what it is. If there is more information in the mailing lists or other project forums, the search engines do not know about it either, however.

The OpenOffice project has struggled mightily after LibreOffice went its own way; back in 2017, an LWN article described some of those struggles. The situation has perhaps gotten a bit better since that time—maintenance releases are coming out more frequently at least. LibreOffice has its own set of problems, of course, but has been cranking out feature releases on a regular basis and has far surpassed OpenOffice in everything but name recognition at this point.

In the end, the bug is not earth-shattering—and is not even considered to be a bug by some. It does seem clear that most users will not even consider the possibility that opening some document will actually reach out across the net to snag some, possibly malicious, content, though. The age-old advice not to open documents from untrusted sources is obviously relevant, but is, just as obviously, roundly ignored.

Fixing those kinds of problems is clearly to the good, even if users need to opt-in to get the protection. Unfortunately, OpenOffice users seemingly have no documented way to do so—or even to know if they need to. It is a rather strange way to run an office suite project.

Index entries for this article
Security	OpenOffice.org/LibreOffice

to post comments

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 4:27 UTC (Wed) by gdt (subscriber, #6284) [Link] (1 responses)

The odd saga of CVE-2012-5639

Posted Jan 18, 2024 20:04 UTC (Thu) by Alterego (guest, #55989) [Link]

Thanks for your very useful comment.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 4:36 UTC (Wed) by smurf (subscriber, #17840) [Link]

> It is a rather strange way to run an office suite project.

One might debate whether it is in fact "run", or simply "getting dragged along, limping badly". After all, dropping it in favor of LO, like everybody else has done, would (presumably) still be too embarrassing.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 6:34 UTC (Wed) by fwiesweg (guest, #116364) [Link] (23 responses)

> The age-old advice not to open documents from untrusted sources is obviously relevant, but is, just as obviously, roundly ignored.

The issue is that people often do not have much of a choice. Sending emails with documents is the suboptimal and insecure, but standard way of operating in many fields. Not opening them is not doing their job for many, which is obviously a non-starter.

We simply need to provide secure-by-default software instead of expecting people stop their work or to jump through a bunch of loops like running an extra VM or clicking a checkbox deep in the settings which not even LWN readers knew about.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 6:45 UTC (Wed) by smurf (subscriber, #17840) [Link]

> We simply need to provide secure-by-default software

Amen, brothers and sisters (and others).

Though the "simply" part isn't that easily accomplished, apparently.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 8:49 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (21 responses)

Browsers were originally designed to solve that use case, and still do if you choose to use HTML as a document markup language.

But: Browsers automatically load external content when requested to do so, and you don't see anyone filing a CVE for that behavior by itself. External content loading is one of the oldest bits of browser functionality, having been implemented very early on in the web's history. So it's difficult to argue that this is not a desirable feature for a document-sharing application. And yes, there are privacy implications, but IMHO those are best solved through some combination of (legal) regulation and selective blocking, not by configuring the software to be broken by default.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 9:41 UTC (Wed) by Wol (subscriber, #4433) [Link] (5 responses)

At my employer, the attempt to lock down our systems so that malicious content can't get in is a real nuisance.

But from what I see in my role as a "Cyber Friend" (aka "user interested in security") it's very much needed.

Having programs *unexpectedly* (and this is the key word) reaching out to the net for random content is very scary - and very dangerous! If I ask my system to reach out, fine. If somebody sends me a (possibly malicious) document that reaches out without my knowledge (or worse, is somehow auto-opened and reaches out without my involvement at all) is opening my company up to a serious data breach.

Cheers,
Wol

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 11:11 UTC (Wed) by smurf (subscriber, #17840) [Link] (3 responses)

Exactly.

Besides, it's not just malicious *content*. The content may well be perfectly innocuous but IP addresses are geolocatable; your physical security may depend on the author of a document not knowing where you are if/when you read it.

Movie plot-level scenarios (i.e. requiring nontrivial levels of suspension of disbelief) which exploit this can be constructed easily. The problem is that there's a real issue behind most implausible far fetched schemes.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 19:53 UTC (Wed) by NightMonkey (subscriber, #23051) [Link] (2 responses)

> Movie plot-level scenarios (i.e. requiring nontrivial levels of suspension of disbelief) which exploit this can be constructed easily. The problem is that there's a real issue behind most implausible far fetched schemes.

Reading and hearing some of the stories of how the State of Israel calls some people before bombing their community help confirm this worry. I don't think it is rare today. Sure, how they do it is secret, but I think it is plausible that IP addresses are part of the process of geolocating people in Gaza and in the West Bank.

One example: https://www.bbc.com/news/world-middle-east-67327079

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 4:34 UTC (Thu) by passcod (guest, #167192) [Link] (1 responses)

In that case it's not particularly secret: Israel controls the civil registry, migration, and issuance of identity documents for Gaza residents. Of course they have everyone's addresses.

The odd saga of CVE-2012-5639

Posted Jan 19, 2024 3:58 UTC (Fri) by paulj (subscriber, #341) [Link]

Israel also controls taxation in Gaza and the West Bank. They control civil registrations and taxation. They hold a lot of information. (And then withhold chunks of the revenue from the taxes due to the PLA, sometimes all of it).

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 3:00 UTC (Thu) by DimeCadmium (subscriber, #157243) [Link]

> document that reaches out without my knowledge (or worse, is somehow auto-opened and reaches out without my involvement at all) is opening my company up to a serious data breach

It's really not, though, in the same way as clicking on a link is not. (Of course, browser 0days and *Office 0days are both possible, but that doesn't stop anyone from clicking links)

Both load content into a document from arbitrary remote sources, and both can reveal things like your IP address to an "attacker".

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 10:24 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

It doesn't just have privacy implications though, it also has implications for e.g. archiving, version control,... when that external content goes away or even just changes. I would argue that any document software is broken by default if it transparently includes remote content.

Not to mention that browser jump through a myriad of hoops to make remote active content (like scripts) even vaguely safe.

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 5:27 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

> It doesn't just have privacy implications though, it also has implications for e.g. archiving, version control,... when that external content goes away or even just changes. I would argue that any document software is broken by default if it transparently includes remote content.

We lost that fight when including external content became possible, which (according to the article) was over 10 years ago. Maybe it's time to acknowledge that that is no longer the world we live in.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 10:40 UTC (Wed) by cesarb (subscriber, #6266) [Link] (2 responses)

> Browsers automatically load external content when requested to do so, and you don't see anyone filing a CVE for that behavior by itself.

Nobody expects a HTML file to be self-contained (even though it's possible), the usual case is that it depends on external resources (images, CSS files, etc). On the other hand, the common expectation for a document file is that it's self-contained (even though depending on external resources is possible), with everything (images, style files, etc) being stored within a single file.

Personally, I'd expect that opening a document which requires external resources (be them from the network, from an absolute path on the C:\ drive which does not exist on my machine, or even from another file in the same directory) to first show me an alert dialog box, similar to the "this document contains macros, are you sure?" warning.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 12:41 UTC (Wed) by smoogen (subscriber, #97) [Link] (1 responses)

> Browsers automatically load external content when requested to do so, and you don't see anyone filing a CVE for that behavior by itself.

> Nobody expects a HTML file to be self-contained (even though it's possible), the usual case is that it depends on external resources
> (images, CSS files, etc). On the other hand, the common expectation for a document file is that it's self-contained (even though
> depending on external resources is possible), with everything (images, style files, etc) being stored within a single file.

> Personally, I'd expect that opening a document which requires external resources (be them from the network, from an
> absolute path on the C:\ drive which does not exist on my machine, or even from another file in the same directory) to
> first show me an alert dialog box, similar to the "this document contains macros, are you sure?" warning.

While the expectation that the document is self-contained, I think the expectation has been false since the mid-1990s for nearly every office suite once web-fonts became a thing. Then when the 'native' form of the documents became either XML or some form of SGML it became even harder as the DTD, fonts, macros, etc might all be referred to a list which the editor would try to find locally and then go to wherever the document said for it to go to. Many documents might have hundreds of artifacts being downloaded from the web. Starting out most of these artifacts were seen as 'wanted/needed' by the writer and viewer of the document, but only when they looked at that particular document.. so having them be 'throw-away' cache made sense versus having to put on a limited drive gigabytes of data that was barely used. [Another large complaint I remember from help desk duty in the 2000's.. I can't open this document because I need these items installed but I have no disk-space...]

Going from the amount of 'why am I getting so many pop-ups' that help desks get from people when that started getting flagged.. adding more pop-ups to say 'this is going to download content from the internet' was probably seen as either adding another 'click-thru' security item or adding more helpdesk costs which companies don't like. And like all unintended consequences, we end up with creating a security problem which isn't easily fixed.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 13:23 UTC (Wed) by Wol (subscriber, #4433) [Link]

> [Another large complaint I remember from help desk duty in the 2000's.. I can't open this document because I need these items installed but I have no disk-space...]

Driven by the assumption that "resource is not finite". I can't remember the details, but I remember trying to point Windows at a network resource. It didn't work (very well). All the help documentation (including MS's own) said "you should cache this on your local hard drive". Didn't it cross anybody's mind that caching a terabyte resource from a server is rather hard when your laptop has a 250GB drive ... ??? (I think it was caching my home directory or something.)

And then there's Windows habit of downloading and caching the resources for every user who's ever logged onto a shared computer. So if you're not admin (and most people using computers like that aren't) the hard drive rapidly fills up with OTHER PEOPLES' crud. Which you can't even see, let alone delete to free up space!

This is all down to that "War of the Workstations" stuff - do you do things the MIT way - get it right, or the New Jersey way - get it out the door. If you really want security, you NEED to do it the MIT way, and not only that, the MIT way tends to *prevent* technical debt building up!

Cheers,
Wol

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 10:57 UTC (Wed) by smurf (subscriber, #17840) [Link] (8 responses)

> So it's difficult to argue that this is not a desirable feature for a document-sharing application

LibreOffice is *not* a "document-sharing application". It's an application to work with documents. On, you know, your computer, which may or may not be connected to the network in the first place. Any sharing you do happens outside of LO, because of reasons.

I want my office programs to not even think of talking to the network unless specifically directed to do so. I also want them to save documents locally instead of fetching bits and pieces (which might vanish at any time) from somewhere else.

There are enough situations where moral or legal requirements compel you to save an immutable copy of a document. How does that even work when part of the document gets loaded from a random place on the net?

LibreOffice is an office suite. It's not a browser.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 13:15 UTC (Wed) by pizza (subscriber, #46) [Link]

> I want my office programs to not even think of talking to the network unless specifically directed to do so. I also want them to save documents locally instead of fetching bits and pieces (which might vanish at any time) from somewhere else.

For most corporate deployments of office programs, "talking to the network" is a mandatory feature that is routinely used. Heck, I'd argue that this is probably also routine in personal settings as well.

This "problem" seems to be an example of "there is no objectively correct default" for all user types.

(Personally I'd be in favor of "block remote resources by default with a warning bar across the top", with a pop-up UI to view the hostnames/etc as well as the allow/deny lists, as there's already other LO precedent for that sort of thing. But I also recognize that 98.3711% of the time the answer will be "allow, of course" leading to muscle memory allowing malicious content through)

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 18:57 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (6 responses)

I want my office programs to not even think of talking to the network unless specifically directed to do so. I also want them to save documents locally instead of fetching bits and pieces (which might vanish at any time) from somewhere else.

That's great, but you aren't the only person who uses office programs, and you don't get to tell everyone else they're using them wrong. There are all kinds of useful use cases for accessing other files from within yours. An obvious one is embedding one office document in another: a spreadsheet in a word processor document, a flow chart in a presentation, etc. It can be very useful if, for example, I can change information in one location and have it automatically update everywhere.

There are also a whole lot of uses for external data sources specifically in spreadsheets. They let ordinary users who don't think of themselves as programmers do things like access and process information from a company database. This is a big use case for companies, and any spreadsheet that wants a second look from business users needs to support it. From the LibreOffice website:

Advanced DataPilot technology makes it easy to pull in raw data from corporate databases, and then cross-tabulate, summarise, and convert it into meaningful information. Real-time data streams can now be integrated in sheets and reports, and factored in calculations.

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 9:23 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

> you don't get to tell everyone else they're using them wrong.
> There are all kinds of useful use cases for accessing other files from within yours.

So you put the linked-to file in question onto a file server and link to it relative to the source. Or you embed it and offer a "refresh" button. Or you ASK THE USER whether to load external content when they load the document. (Maybe offer an option to cache that decision, per link destination.)

What you DO NOT do is to blindly access random external resources just because somebody sent you a file. That's not "telling people they use LibreOffice wrong", that's "asking the LO developers to please not default to shoddy security practices".

It'd be very nice if we lived in a world where loading random office document content from random sources isn't unsafe. Unfortunately we don't, and as long as security agencies are hoarding exploits instead of getting them fixed (among other reasons) we won't get there any time soon.

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 12:38 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

It's all very well saying peoples' jobs rely on them opening random documents that may access external content.

But that can be read two ways, either they need the document to access said external content in order to do their job, OR allowing the document to access said external content will cost them their job.

Seeing as I work in an industry (supermarkets) where I have access to a LOT of sensitive information (and no I have neither the desire, NOR the knowledge, to be able to access most of it) that latter case could easily cost not only me, but many of my colleagues, their job.

I've already had to deal with a case recently that could have been extremely serious (as in existential serious) for my employer. I merely dealt with the fallout from someone else's mistake. I'd hate for someone to have to deal with the fallout from me making a mistake like that.

Cheers,
Wol

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 13:49 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

It's also extremely unusual for someone's job to rely on opening documents that access arbitrary external content. More commonly, if you need to access external content, it comes from a limited set of sources; for example, you might need to access content stored on your company's managed systems, but not arbitrary Internet content. This implies that, assuming you have a competent and well-run IT department, an allowlist of sources of external content, where sources not on the allowlist are blocked completely, would be sufficient to protect users and wouldn't affect people's ability to do their jobs.

Of course, as with anything else, the hard part is making sure that the assumption is true. It's all too common for IT departments to be a mixture of incompetent and badly run, such that there's no way to handle exceptional cases or change to the norm in a speedy but safe fashion.

The odd saga of CVE-2012-5639

Posted Jan 11, 2024 14:10 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

Personally I could care less about badly-run IT departments. I care about "default-secure", which (a) doesn't even need an IT department and (b) negates quite a few opportunities for incompetence.

On the other hand, a "run in secure mode" button that's hidden three layers deep in some option dialog, defaults to Off, and doesn't allow for a whitelist, is (in some sense) even worse than not having the option at all.

The odd saga of CVE-2012-5639

Posted Jan 12, 2024 2:37 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

> Personally I could care less about badly-run IT departments. I care about "default-secure", which (a) doesn't even need an IT department and (b) negates quite a few opportunities for incompetence.

The problem is that there's no obvious attack which can meaningfully be carried out against a user who doesn't work for some organization with an IT department,* but would be prevented by blocking external content. Sure, there are tracking pixels, but think about it: From the user's perspective, what is the negative consequence caused by a tracking pixel? The sender gets a read receipt? That's hardly worth discussing, by the time you have convinced a user to download and open an attachment. Heck, you could just put the document on your own server and tell the user to click a link to download it, then you don't even need the user to open the document. Do you really think the average non-technical user is going to notice the difference between clicking a link to download something and downloading an attachment?

* The military, the NSA, etc. are all assumed to have IT departments, so we need not concern ourselves with the "my workstation is airgapped and all the ports are filled with epoxy" stuff. Even so, that seems like a problem that solves itself ("airgapped" means no external content will load).

The odd saga of CVE-2012-5639

Posted Jan 19, 2024 4:01 UTC (Fri) by paulj (subscriber, #341) [Link]

File servers have kind of disappeared. Gdrive / Drivebox kind of web-based file storage is the common thing now.

The odd saga of CVE-2012-5639

Posted Feb 1, 2024 19:10 UTC (Thu) by fest3er (guest, #60379) [Link]

One primary difference between browsers and office suites is that browsers usually run in sandboxes and, thus, have little (or controlled) access to the local system. OTOH, an office suite has access to all parts of the local system that its running user has.

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 13:00 UTC (Wed) by foom (subscriber, #14868) [Link]

The changes since the last release are here:
https://github.com/apache/openoffice/compare/AOO4114-GA.....

This seems to be the relevant change: https://github.com/apache/openoffice/commit/f8c074b1219af...

Which it seems adds more calls into a pre-existing functionality of asking the user for permission to fetch content.

The odd saga of CVE-2012-5639

Posted Feb 24, 2024 1:52 UTC (Sat) by Curan (subscriber, #66186) [Link]

Just a note on the "missing" date for the linked Debian "report": that is not really a report. The security tracker imports any (or at least almost) any CVE affecting a Debian package. Additional data can be added through various means. But the date of the tracker page would always be the one of the original report.

As a paying customer here, I would hope LWN staff would know this, since Debian is one of the core Linux distributions, if not the most important one.