Comma Separated Vulnerabilities

The really infuriating thing about this report is the message these terrible applications give to users. &quot;Links to other files?&quot; And the inquiry about whether those &quot;links&quot; should be &quot;updated?&quot; That&#x27;s a ridiculous, terrible, message to express &quot;remote code execution.&quot; Just as bad is &quot;automatic update of links.&quot;<p>The hell? If I were reading this (as a sophisticated user who isn&#x27;t a security expert), I&#x27;d just assume there was some kind of weird document embedding thing going on. Not that &quot;link to other file&quot; meant &quot;RUN ARBITRARY APPLICATIONS AND PROBABLY EXECUTE ARBITRARY CODE.&quot;<p>Even the warning about &quot;To access this data Excel needs to start another application&quot; is incredibly deceptive. The data in a CSV is perfectly damn accessible without Excel opening anything else. It ought to say &quot;to execute the commands embedded in this data, Excel needs to start another application,&quot; so that people bloody well know that they&#x27;re not just <i>viewing data</i> but they&#x27;re actually <i>doing something.</i><p>Horrible, horrible, horrible communication.

re: &quot;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.&quot;<p>Whoah, that&#x27;s putting the blame in the wrong place. Spreadsheets shouldn&#x27;t look for formulas at all in plain csv files. That&#x27;s not what they&#x27;re for.

I&#x27;ve found that spreadsheet software, notably Excel, tends to be &quot;over-helpful&quot; in trying to determine the format of the data it&#x27;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 &quot;02-04&quot; should somehow be a date will be familiar with this.<p>It should not be surprising then, that this type of guessing behaviour could lead to exploitable vulnerabilities.

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).<p><a href="https:&#x2F;&#x2F;hackerone.com&#x2F;reports&#x2F;72785" rel="nofollow">https:&#x2F;&#x2F;hackerone.com&#x2F;reports&#x2F;72785</a><p>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.<p>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 &quot;(2014)&quot; on the end of the title.

Just implemented a CSV importer&#x2F;exporter for a big release and this document came in super helpful.<p>Are there any CSV exploits that can&#x27;t be solved by just prefixing fields that start with &quot;=&quot;, &quot;+&quot;, &quot;-&quot;, and &quot;@&quot; with an apostrophe?

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.