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.
That's an astute observation.
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.
There is a document embedding feature in Office documents. Perhaps OO is just reusing the same warning for both situations.
If you know the basics of OLE 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.
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.
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.
It should not be surprising then, that this type of guessing behaviour could lead to exploitable vulnerabilities.
They cited this link in their report.
Thank goodness that A. W. and K. got this right 35 years ago, interpreting data inputs as numbers and strings. Pity about the regression.
Are there any CSV exploits that can't be solved by just prefixing fields that start with "=", "+", "-", and "@" with an apostrophe?
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.