Dokuwiki: CVE-2018-15474: CSV Formula Injection vulnerability

[splitbrain]

The following was reported directly to me by Jean-Benjamin Rousseau from SEC Consult (Schweiz) AG

Vulnerability overview/description:

The administration panel of the application has a "CSV export of users" feature which allows the export of user data (username, real name, email address and user groups) as a CSV file. On the registration page, it is possible for an attacker to set certain values in the Real Name field that - when exported and opened with a spreadsheet application (Microsoft Excel, Open Office, etc.) - will be interpreted as a formula.
This puts the administrators who open those malicious exported files at risk. Exfiltration of sensitive data or even the execution of arbitrary code on the local machine of the victim will be the result. The final impact depends on the used spreadsheet software on the client of the victim.

Proof of concept:

Registration URL:
http://www.example.com/doku.php?id=start&do=register

When the registration request is submitted, the following parameters are sent in a POST request:
sectok=&do=register&save=1&login=login_parameter&fullname=evil_csv_formula_injection_payload&email=email_address

The "fullname" parameter is not sanitized before being stored and during the CSV export. An attacker can inject different CSV formula payloads in the fullname parameter.

For example:

=cmd|'/C calc'!A0

As soon as the file gets opened in Microsoft Excel, the program calc.exe is launched. Different warnings might pop up. However, these warnings are usually ignored because the file comes from a trusted source.

[splitbrain]

In my opinion this is not a security problem in DokuWiki. There is no such thing as "CSV Forumulas". CSV is a plain text format that has no active content. Clients reading a CSV and interpreting the content as commands are misinterpreting the file format in my opinion.

If there is a vulnerability at all, it's in the interpreting software (eg. Excel) however as pointed out in the advisory, Excel will warn ask about executing commands - adhering those warnings is the responsibility of the user.

I don't see that we should even attempt to "fix" this in DokuWiki, nor would I have any idea how - since we do not have any assumptions about user's full names.

[Chris--S]

After reading https://blog.zsec.uk/csv-dangers-mitigations/ and as far as I can discover there is no real mechanism for encoding a dangerous character (as there shouldn’t be any), one reasonable thing would be to alert admin the file is unsafe for some spreadsheet programs if fields begin with one of a character blacklist.

From the looks, making a file safe for excel & co is fairly straightforward, add an equals sign before the field escape character, so we could have an “export for dangerous spreadsheets” option!

[KervyN]

A colleague reminded me that you could quote the textfield in the csv. How else could you export something with a comma?

But this is more a general thing I would never have thought about.

[phy25]

Just read about a blog post about CSV injection: https://www.wordfence.com/blog/2018/08/ninja-forms-security-updates-what-you-need-to-know/

Ninja Forms seems to have a mitigation patch about this, which we may consult from, if anyone is interested in this.

[micgro42]

From @phy25's link:

That said, in 2014 LibreOffice Calc and OpenOffice Calc both removed the DDE command execution functionality which allows this sort of command execution.

And that MS Excel hasn't done this step is the actual security issue.

[splitbrain]

@KervyN we of course escape stuff that's special to the CSV format like commas. That has nothing to do with the problem here. Excel interprets the contents after the CSV was parsed.

@phy25 their "solution" is to prepend the content with a ' - that actually modifies the cell content for all sane CSV processors including DokuWiki. With a "fix" like that implemented, exported users would no longer be imported the same as in the original wiki, defeating the purpose of the import/export feature.

Now, one could argue that it is okay to sacrifice some "weird" user names for the benefit of "safety" of Excel users, but so far nobody actually even made that argument. And I believe it's not our task to save Excel users from themselves.

[ehdis]

@splitbrain The point of view shouldn't focus the end of the chain (MS Excel etc.). The real cause is the missing sanity check on users input on dokuwiki side ( =|'/! ). This can lead to the mentioned symptoms above or to new ones in the future! Making assumptions about users full name is not rocket science (on line preg_replace). I suggest to handle this case with care because it shows how carefully best practices (OWASP) are used while developing dokuwiki further. Because the trust of your user base is your capital ...

[splitbrain]

@sheesupport no. We're talking about the full name of the user here. They are free to pick whatever they want. We ensure that it is properly escaped when used. We do not make assumptions about what our users want to set as their name. This has nothing to do with sanitizing input.

[selfthinker]

Related, but not a security issue: When a user names themselves "007", Excel would read that as "7". And when you save the CSV file again, it would also save it as "7", corrupting the user name.
I first assumed escaping or quoting properly would fix both issues. But reading more about it, it's not that easy at all and also handled differently by different spreadsheet applications.