Comma Separated Vulnerabilities | Hacker News Reader

Comma Separated Vulnerabilities

contextis.com

201 pointsgfalcao25 comments

The really infuriating thing about this report is the message these terrible applications give to users. "Links to other files?" And the inquiry about whether those "links" should be "updated?" That's a ridiculous, terrible, message to express "remote code execution." Just as bad is "automatic update of links."

The hell? If I were reading this (as a sophisticated user who isn't a security expert), I'd just assume there was some kind of weird document embedding thing going on. Not that "link to other file" meant "RUN ARBITRARY APPLICATIONS AND PROBABLY EXECUTE ARBITRARY CODE."

Even the warning about "To access this data Excel needs to start another application" is incredibly deceptive. The data in a CSV is perfectly damn accessible without Excel opening anything else. It ought to say "to execute the commands embedded in this data, Excel needs to start another application," so that people bloody well know that they're not just viewing data but they're actually doing something.

Horrible, horrible, horrible communication.

>"Links to other files?" And the inquiry about whether those "links" should be "updated?" That's a ridiculous, terrible, message to express "remote code execution."

There is a document embedding feature in Office documents. Perhaps OO is just reusing the same warning for both situations.

I agree. I've seen these warnings from time to time and assumed like you did that the other person had linked to another spreadsheet or used OLE or something. I clicked no because I was sure I didn't have whatever other file it might be linking to, not because I was concerned it might be insecure.

> It ought to say "to execute the commands embedded in this data, Excel needs to start another application," so that people bloody well know that they're not just viewing data but they're actually doing something.

That's an astute observation.

Somewhat related:

Awhile back I remember seeing a demo of some Mozilla tech that would let one rotate a web page and then view a 3d "stack" of all the DOM elements. A bit like each layer was made up of different colors of lego blocks.

Is there some similar visualization tool to help distinguish data from code?

For example, imagine I want to use some scissors to clip some daisies on a hilltop. I eyeball the daisies I want. When I pick up the scissors they snap a picture of the daisies and cut 1000ft below until they split into the bedrock. Consequently, a demon's fiery arm shoots out the hole holding my scissors, violently cuts the daisies, then picks them up and offers them to me as a low, rumbling voice announces: "Daisies."

Now I don't know about anyone else, but I think that experience would make me a wee bit cautious about picking flowers. Or at least more than I would be merely by reading a man page.

Edit: I guess to be sensible, the demon's arm would need to recede back into the bedrock and heal the split.

3D stack of DOM elements wasn't just a tech demo, it was actually part of the devtools. Removed because no one reimplemented it in a way that's compatible with multiprocess Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1086492

An amazing feature which was moved to a still accessible extension. Sadly I can't remember the name right now but I found it very recently. Makes understanding HTML nesting rapidly apparent.

Is this it? https://addons.mozilla.org/en-US/firefox/addon/tilt/

Yes. (And it does not work with e10s.)

I'd just assume there was some kind of weird document embedding thing going on.

If you know the basics of OLE[1] you'd be aware that running another application is the entire concept behind how it all works --- and in this context, the warning message isn't all that bad: note that it says "Remote data not accessible", suggesting it's not the data in the CSV itself. Furthermore, the final sentence asks whether to start CMD.EXE, which should hopefully surprise you enough into clicking No.

[1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding

"If you know the murgle gurgle flurgle..." never mind, you've already lost the attention of 99.99999% of Excel users. As for the others, I know what OLE is (to the tune of "a big gaping security hole"), yet I still find the wording incredibly confusing.

Yeah, exactly. And, I'd add, the attention even of sophisticated Excel users who don't actually write code for Windows.

re: "Spreadsheet software could take steps to mitigate some of these attacks, but preventing formula injection is ultimately the responsibility of every application that generates spreadsheets containing user-supplied content."

Whoah, that's putting the blame in the wrong place. Spreadsheets shouldn't look for formulas at all in plain csv files. That's not what they're for.

Exactly. Putting junk apostrophes in CSV files just means that when I import CSV files into my database I now need to figure out if the apostrophe was supposed to be there or was inserted by the exporting software.

Spreadsheet software should import formulas as plain text formatted cells, and have an optional checkbox to "also import formulas" for people who are trying to interchange spreadsheets they created.

I've found that spreadsheet software, notably Excel, tends to be "over-helpful" in trying to determine the format of the data it's reading in, no doubt in an attempt to help the less-knowledgeable user; anyone who has ever had it mangle imported data by e.g. guessing that "02-04" should somehow be a date will be familiar with this.

It should not be surprising then, that this type of guessing behaviour could lead to exploitable vulnerabilities.

Or, what to think of the sheer idiocy of Excel blindly throwing away integers it deems too large, replacing them by floats...

FWIW, if the imported data comes from a web app, which presumably generates it with JavaScript, the damage is already done...

All these features (like DDE) should be disabled by default, and should only be possible to be enabled by means of an obscure and hidden menu item that nobody can find.

Was just reading a vulnerability disclosure of an example of this at Hackerone last night (for Hackerone).

https://hackerone.com/reports/72785

They cited this link in their report.

You mean to say that, whenever I load a CSV file into LibreOffice, anything that looks like code gets executed? Excuse me one moment while I patch that program with rm -rf.

Thank goodness that A. W. and K. got this right 35 years ago, interpreting data inputs as numbers and strings. Pity about the regression.

This probably should have a "(2014)" on the end of the title.

Anyone know the current state of these vulnerabilities? The post says it was updated in April 2016.

They still exist and (as far as I know) there are no plans to do anything about them. We (thankfully) were alerted to this issue by HackerOne before it was an issue, but this remains an absurdly easy attack vector...

Just implemented a CSV importer/exporter for a big release and this document came in super helpful.

Are there any CSV exploits that can't be solved by just prefixing fields that start with "=", "+", "-", and "@" with an apostrophe?

You might consider prefixing other fields with an apostrophe to avoid them being misinterpreted as numbers or dates.

Unfortunately, even if you put an apostrophe on everything, problems remain:

- the apostrophes are non-standard and assure all other CSV-handling tools get the wrong, apostrophe-prefixed values

- Excel itself doesn't escape fields on output, so if someone loads your exported file into Excel, saves it and reloads it, the exploits come back

Excel is a quite frighteningly terrible tool for handling CSV.

Old as me, this stuff is. Little consideration, security was for windows programmers when DDE was made. Exploits leveraging stuff from Windows 3.1, I see often.

Reply on news.ycombinator.com