You have no doubt heard by now that Microsoft is bringing Python to Excel.
And if you hadn't heard that news, you no doubt heard a strange noise in the distance as data scientists collectively rejoiced and infosec teams collectively groaned.
But before you jump to any rash conclusions on either side, let's understand some things about it.
For my fellow "younguns", a little history: About three decades ago, sometime around (I believe) 1993, Microsoft brought Visual Basic to Office and data entry workers celebrated (Presumably. I was only 2 years old at the time, so I'm making this bit up). You could now automate all kinds of arduous tasks, cleanly formatting your spreadsheets to your (or rather, your management's) hearts content. I myself wrote a macro just a couple weeks ago to automate a significant amount of table formatting and data cleanup. But hackers also rejoiced because VB provided access to low level system functionality that would enable them to execute all sorts of things outside of the app. It took attackers almost no time at all to realize this, and the first known incident of a macro-driven attack occurred in 1995, nearly 30 years ago. (source)
Somewhere along the way, Microsoft implemented a warning to the presence of macros via a banner notification that if you've worked in an office for more than 5 minutes, you've no doubt seen at some point. A user would then have to intentionally click a button to enable the macro. This of course didn't exactly solve the problem, but it at least slowed things down a bit. So long story short, as with basically any technology going back to the invention of the wheel, people have found great utility in intended use, as well as nefarious use of macros.
to 2023, August 22, specifically, and Microsoft announced that Python
scripts will now be supported in Excel. Given the aforementioned macro
history, its clear to see why there's both skepticism and rejoicing.
Python is an incredibly powerful scripting language, making use of an
unimaginable number of libraries to create and automate just about
anything you can dream up. But that means you can also do some REALLY...
err... creative things with it.
it's at this point that the astute reader will say "oh boy, I see where this is going."
But, Microsoft thought of this. Maybe. Hopefully.
The implementation of Python in Excel makes use of a few controls that should make it mostly safe. We should all know better by now than to believe that its safe but it's at least safe-adjacent.
The first thing to know is that, at least by design, any Python executed in Excel is run in isolated containers in Azure. This means that it will not have access to your local system or account. According to documentation (and this point is admittedly a bit confusing for me) it also will not have network access. The code does not have access to, and cannot call other formulas, charts, macros, etc. Also, taking a page out of the macro history book, Excel's protected view applies in the same way with Python content as with macro content. That is to say, if you load a worksheet with Python that was downloaded from the internet or other untrusted source, the code will not run without your acknowledgement and acceptance. Additionally, and with perhaps uncharacteristic foresight, Microsoft also designed this process such that if a user accepts the risk and allows the external content, this content will still be executed in a separate, isolated Azure container, thus eliminating any potential interaction between code from that sheet, and any code from any other sheets a user may have open at the time. They've also committed to a routine patch management process to ensure that the Python environments are kept up to date.
And there is one last, considerably important measure that Microsoft put in place to ensure safety, which is that they limited the functionality at the library level. By partnering with Anaconda, the implementation of Python in Excel limits it to a specific set of curated libraries. Now before I get any hate mail, I fully understand that the Python codebase is still perfectly capable on its own. But, limiting the available libraries is another step, one which I would argue will go a long way, in limiting low-effort attacks.
Finally, there is one additional control you can enforce yourself - a simple registry key, allowing you to display a warning, or block Python in Excel execution entirely.
To do this, create a new DWORD named PythonFunctionWarnings in HKCU\software\policies\microsoft\office\16.0\excel\security
Available values are:
0 - Disable warnings
1 - Temporarily block and display a banner to users when Python formulas are present, allowing users to enable content if they choose to
2 - Disable all Python functions from running in Excel
If you would like to script this, you can simply use the following commands:
reg add HKCU\software\policies\microsoft\office\16.0\excel\security /v PythonFunctionWarnings /t REG_DWORD /d 0 /f
reg add HKCU\software\policies\microsoft\office\16.0\excel\security /v PythonFunctionWarnings /t REG_DWORD /d 1 /f
Python in Excel Disabled
reg add HKCU\software\policies\microsoft\office\16.0\excel\security /v PythonFunctionWarnings /t REG_DWORD /d 2 /f
Hope this helps! Stay safe out there!