Interestingly, Google specifically excludes CSV vulnerabilities like that from their bug bounty program.
> CSV files are just text files (the format is defined in RFC 4180) and evaluating formulas is a behavior of only a subset of the applications opening them - it's rather a side effect of the CSV format and not a vulnerability in our products which can export user-created CSVs. This issue should mitigated by the application which would be importing/interpreting data from an external source, as Microsoft Excel does (for example) by showing a warning. In other words, the proper fix should be applied when opening the CSV files, rather then when creating them.
To add a bit of color here, Google is correct to exclude CSV vulnerabilities. There is no way (through this vulnerability) to compromise a Google host, a user account managed by a Google host or sensitive data associated with a user account.
As framed, this is kind of similar to using a Google web tool to edit an XML file, export it and compromise someone using external entity injection. In that context, you're not really compromising Google, and you're not using Google as a medium to automatically compromise many Google users at once. Google is only peripherally involved in the process.
What would qualify for a bounty is code/script execution on a Google host using a CSV file, maybe through something like Google Trends Correlate (https://www.google.com/trends/correlate). Either reflect the CSV contents in a publicly accessible location with a mismatched content-type or leverage an arbitrary file upload error to execute a malicious payload disguised as a CSV on the server. But just exporting a CSV from a Google host is not really a vulnerability in Google.
By the way, for people who are interested in bug bounties, it looks like the page I linked hasn't been updated since 2011. Might want to check it out.
It probably helps that Google's applications encourages their users to open spreadsheets in Google Sheets, instead of office software running on the users' machines.
If you work on a web application where users can generate reports that contain input from other users, and a common workflow is for users to download those reports and open them in Excel, they aren't going to be happy if your site is a vector for attacks. Saying "Oh, but it's an attack against your laptop, not against our servers; WONTFIX." is going to be tough to justify.
> > A lack of filtering on user CSV output that could allow an attacker to run arbitrary code on an administrator's computer.
Iff the user has Excel, and explicitly allows it to run macros in a CSV file. It's already a stretch to call this a phpMyAdmin vulnerability, much less a "medium severity" one.
> > Improper cookie invalidation that could allow an attacker to unset internal global variables.
From the PDF report:
> Note: Because of the large amount of global variables, and the relatively short nature of this assessment, NCC Group was unable to fully determine the impact of this vulnerability.
It might be serious, but they didn't have enough budget to make a proper analysis.
No, it means we understand there are theoretical security issues with global variables, but cannot determine if they're actually applicable or exploitable in this software.
A theoretical security vulnerability isn't really a think - it's just a bug. Either it's exploitable, and thus a security vulnerability, or it's a bug and isn't,
I would venture that to do so would devolve into a full source audit, which seriously increases the scope of the test. Full source audits are likely to consume ten times or more calendar effort.
Performing a full source audit is going to result in sticker shock for all but the most well-funded.
> Improper cookie invalidation that could allow an attacker to unset internal global variables.
Those don't count as serious issues? Props to them for making the report public though.