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

The odd saga of CVE-2012-5639

Posted Jan 10, 2024 6:34 UTC (Wed) by fwiesweg (guest, #116364)
Parent article: The odd saga of CVE-2012-5639

> 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 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.