I'm skeptical that Excel does this without prompting. Microsoft takes these kinds of vulnerabilities—opening a data file causing ACE—seriously. Do you have more information?
> Microsoft takes these kinds of vulnerabilities (...) seriously.
Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
From those 439 around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing.
I'd argue that "taking this seriously" is the opposite of the sheer amount of those CVE IDs.
And these are only the vulnerabilities we publicly know of, there are far worse VBA exploits being traded on dark markets.
The reason why Microsoft took so long to deprecate these VBA APIs is that large enterprise-grade organizations do almost everything in Excel. From querying a database server to storing a financial report remotely on a mounted net share drive to even including another external file for the inclusion of modules or methods. It really makes you wannacry.
> Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
Sure, but there's a difference between having a large codebase to cover and what is being discussed above. Nothing you've said is contrary to GP.
I am willing to counter any bet that Excel formulas will open an external program without prompting.
> around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing
Exploits and macros are orthogonal. Macros don't require exploits to run, and I've never seen an exploit bother running a macro. It already owns the process at that point. It can do anything it wants.
> The reason why Microsoft took so long to deprecate these VBA APIs
Microsoft isn't deprecating anything, just disabling macros for files with ZoneId=3. This won't be a particularly effective change in the near term given the practical realities of how people work*, but it's long overdue.
* Roughly what will happen at mid-sized+ companies: 1) New feature is enabled. 2) New feature breaks a bunch of existing workflows. 3) IT is flooded with tickets. 4) New feature is disabled with plans to redeploy with exceptions for finance and other teams whose workflows were broken. 5) Everyone gets busy with other projects and new feature is never revisited.
I wouldn't call it serious, more like indifference. Microsoft has been watching viruses and malware spread by emailed office files for 25+ years. They listen to their users when users want insecure features, and are fanatically committed to only incrmeental changes and backward compatibility - like they do in their other products. Some of this of course is the field of industry called anti-virus software, where glorified blacklists of previosuly observed harmful files are dressed in security theater costumes and MS users are guilted into paying various large costs for them.
This bit of news shows that there are people at MS who takes the vulnerabilities seriously as well, but they very rarely have the influence to effect change if it's weighted against anything else.
It prompts about enabling macros, generally. I haven't tested in the most recent versions of Excel but we see this about once a year at clients. You can test it yourself by with a test CSV like:
I just tried that CSV in Excel for Windows and it gave two warnings about it being insecure, had the disabled button default each time, and even 'enable' each time it still didn't run that cell.
Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
Some examples:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Excel
From those 439 around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing.
I'd argue that "taking this seriously" is the opposite of the sheer amount of those CVE IDs.
And these are only the vulnerabilities we publicly know of, there are far worse VBA exploits being traded on dark markets.
The reason why Microsoft took so long to deprecate these VBA APIs is that large enterprise-grade organizations do almost everything in Excel. From querying a database server to storing a financial report remotely on a mounted net share drive to even including another external file for the inclusion of modules or methods. It really makes you wannacry.