Relatedly, I was recently horrified to learn that not only will Excel (and LibreOffice Calc) automatically parse formulas in plain CSV files, but there is also a formula that will _run external programs_.
Yep. To add insult to injury, for many years there either wasn’t a setting to disable loading of external programs or doing so required a subscription of some kind to a MS enterprise license/endpoint/policy management feature.
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.
I've come to the conclusion that absolute security is a fool's game, sort of like never getting sick. You have a Turing machine, you have a tape, it's not going to be secure. It's better to invest in research on an adversarial "immune system", so to speak.
This is absolutely correct! Modern technical security practice preaches defense-in-depth. Over a long enough period of time, you WILL be compromised. It’s much more effective to plan for it and mitigate the damage than it is to attempt perfect security.
The trick is to make sure you have good network segmentation, don’t allow apps/users more access than they need, and have reliable monitoring and anomaly detection in place so you can respond rapidly to breaches that do occur.
The only problem with that take is that people will hear it and remember “don’t attempt security because it’s hopeless”. It’s the same problem that comes from people discussing premature optimization and using it as a reason to skip simple and obvious performance improvements.
Nuance has a way of being lost in advice like that.
Like many things, it's about how far into the diminishing returns you want to go. At some point it's more effective to apply further investment to other parts of the ecosystem.
My own conclusion for the security of a small business was to set up a honeypot - a virus needs to search for vulnerabilities to transmit itself, and that search can be detected. Any virus that doesn’t search for vulnerabilities is much more benign.
That might be how worms work, but it’s not going to protect someone from installing a keylogger or a RAT from opening an infected Excel spreadsheet in an email, for example.
That’s much more reactive than proactive either way. Better as a secondary measure for a large business than as a primary measure for a small business.
Wait until you learn Windows has a default file handler for JavaScript (wscript.exe), which can execute external applications, write files and much more.
