Extension can recursively delete all system files

[ascendedguard]

This has happened twice now, once for me around a year ago, and twice now for a colleague as I was viewing him in a meeting.

It appears if you have the OOXML Viewer tab open, sometimes it will be working even though no file is open yet. When this happens, we both noticed all files on our desktop went missing (but not folders). Further investigation reveals that all files on the file system get deleted (no folders) recursively from the root of the C:\, although it tends to error out at some point so not all files get deleted, and system files like C:\Windows don't get deleted since Code would not have access to that without escalation. In my case, it deleted a good amount of C:\Users<username> folder including documents, downloads, desktop, along with all repos stored at C:\Projects\, amongst other folders.

When I looked into it about a year ago, IT used our monitoring software and did trace back the date/time when the files got deleted to be within a minute of the OOXML Viewer extension being installed in VS Code, so it probably lined up with me trying to open a file.

When watching my coworker (who is not a developer), he continued experimenting with it since he had already had his files deleted - he had no folder open yet and instead tried to open a test .docx from his desktop directly (which was incorrect, but he didn't know how to open it correctly). the test file on his desktop got deleted a second time when attempting to open it. He then opened the folder as he was supposed to but when he did, the OOXML Viewer tab disappeared from the explorer view, then we checked and the OOXML Viewer extension itself had been fully deleted and needed to be reinstalled.

Both systems were Lenovo laptops with Windows 10. The issue occurred today on the latest released version, although like I said, it happened to me around 1 year ago.

Looking through the code, I see the deleteFile section that does { recursive: true, trash: false } and I can only assume there's some situation where a valid path isn't being passed in, so it must be defaulting to \ instead.

[mikeebowen]

Hi @ascendedguard, Do you have a consistent repro scenario? The viewer only writes and deletes files to within the ExtensionContext's storageUri, which is a "uri of a workspace specific directory in which the extension can store private state". The delete command with { recursive: true, trash: false } is part of the vscode extension API and fails with an invalid path; it does not default to \.

If you have a consistent repro please send it and I will create a VM and investigate this.

[ascendedguard]

Understood.

I'll see if I can reproduce in a Windows Sandbox instance - I didn't reproduce it after my first time in my original laptop, it seemed to only happen when I first installed the extension, but it functioned fine afterwards.

For my coworker, it seemed to also be when first launching VS Code in a new window after newly installing the extension. It was also the first and only extension he had installed immediately after installing VS Code.

[ascendedguard]

I just reproduced it very easily in Windows Sandbox. This is on a different computer than the first 2, a custom built PC running Windows 10.

1. Opened a new Windows Sandbox instance.
2. Created a new "test.txt" file on the desktop.
3. Open Edge, download and install Visual Studio Code for Windows 10
4. When done, opened VS Code, opened the Extensions tab, searched for OOXML Viewer, and installed.
5. Open the explorer tab in VS Code
6. Clicked on the OOXML Viewer tab at the bottom. It showed a loading indicator under the "OOXML Viewer" bar, and "Activating Extensions..." appeared on the status bar. Captured a screenshot below of what this looked like.
7. Within about 2 seconds of step 6, the files on the desktop all disappeared, and all icons on the start bar lost their icons. I also confirmed VSCodeUserSetup-x64-1.96.0.exe had been deleted from the Downloads folder.

I HIGHLY recommend you don't test this on your main machine, do it in a VM, since it will delete everything.

[ascendedguard]

Looking at the extension logs, they're not too helpful:

2024-12-17 19:05:34.781 [info] Starting 'OOXML Viewer': {
    "preserveComments": true,
    "maximumOOXMLFileSizeBytes": 50000000,
    "maximumNumberOfOOXMLParts": 1000,
    "maximumXmlPartsFileSizeBytes": 1000000
}
2024-12-17 19:05:34.781 [info] Resetting the OOXML viewer

The VS Code main log isn't helpful either, although it does seem to show a file got deleted 2 seconds after the OOXML viewer logs:

2024-12-17 19:04:48.581 [info] update#setState disabled
2024-12-17 19:04:48.582 [info] update#ctor - updates are disabled due to running as Admin in user setup
2024-12-17 19:05:36.697 [warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted
2024-12-17 19:05:38.895 [error] [File Watcher (node.js)] Failed to watch c:\Users\WDAGUtilityAccount\.vscode\extensions for changes using fs.watch() (Error: EPERM: operation not permitted, watch, undefined)

[yuenm18]

Hi @ascendedguard, I was able to reproduce the issue using the steps you provided. Can you check if this build fixes it for you?
ooxml-viewer-2.0.2.zip

[ascendedguard]

Hi @ascendedguard, I was able to reproduce the issue using the steps you provided. Can you check if this build fixes it for you? ooxml-viewer-2.0.2.zip

I get an error if I try to install from the .vsix. Just unzipped and selected Install from VSIX on a new VS Code install:

Extract: End of central directory record signature not found. Either not a zip file, or file is truncated.

VS Code info:
Version: 1.96.0 (user setup)
Commit: 138f619c86f1199955d53b4166bef66ef252935c
Date: 2024-12-11T02:29:09.626Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.19041

[yuenm18]

ooxml-viewer-2.0.2.zip
Sorry, can you try this one. I think something went wrong when I zipped it.

[ascendedguard]

Looks good to me 👍