Arbitrary Code Execution via JavaScript Queries (CVE-2021-42057)

Describe the bug

I discovered a way to craft malicious markdown files that will cause the obsidian-dataview plugin to execute arbitrary commands on users’ systems. This is due to the unsafe use of eval within the evalInContext function located in src/api/inline-api.ts.

This has been assigned a CVE of CVE-2021-42057 for tracking.

To Reproduce

The following proof-of-concept can be used to display a file on a user’s system by executing the cat command:

```dataviewjs
require("child_process").exec("cat /etc/passwd",(_0,stdout,_1) => dv.span(stdout));""
```

A malicious user could leverage this vulnerability to execute arbitrary code on other users’ systems by getting them to open an untrusted markdown file. This is especially dangerous in environments where users share vaults.

Expected behavior

DataviewJS should not make an unsafe call to eval using user supplied input.

Additional Context

Shortly after we privately disclosed this issue, @blacksmithgu promptly changed the default behavior of Dataview to no longer enable JavaScript Queries by default (see release 0.4.13). This helps protect new dataview users and provides a way for existing dataview users to mitigate this issue by disabling the JavaScript Query functionality when opening untrusted markdown.

@blacksmithgu is currently working on additional solutions and provided permission for us to open a public issue here for tracking.

[kurtharriger]

From my perspective js execution is a significant feature that I don’t want to see removed.

I do not agree that arbitration execution of dataview queries within trusted markdown code is a security vulnerability.

Downloading a bash script or any from the internet is not in itself harmful as it wont do anything until you execute it. And you should only execute code from trusted sources.

The question then becomes do I trust the markdown files in my vault.

Yes, I wrote them and if I find a snippet of obsidian markdown online containing dataviewjs I am certainly going to review it before copying it into my vault.

However, it is not generally expected that markdown files contain executable code and thus I fully agree that it should be disabled by default.

The user has already acknowledged that enabling plugins allows arbitrary code execution and starts with plugins disabled.

The plugin also requires enabling js explicitly.

Could more be done? perhaps. It might be a good idea to create a .dataview/trusted file with list of markdown files. If dataview detects js in a file not in this list it could prompt the user.

But I personally don’t want to be prompted every time I generate a new markdown file from my daily notes template.

Enabling this feature does require the user to be mindful of the code he adds to his vault but that in itself does not make it a bug.

I also do not want the js to be “sandboxed” in fact I want to call http endpoints to import tasks from jira and execute a shell script to pull in my google calendar.

I could potentially make these into plugins, but I love the ability to use dataviewjs to prototype these things.

[blacksmithgu]

@kurtharriger @KjellConnelly I agree with both of your points. To be clear, I am absolutely not removing JS functionality (I use it for everything personally), and I am also trying to avoid annoying security popups since people will just always press “Yes” on them anyway by the time they reach them (if you don’t trust the code, you wouldn’t copy it into your vault in the first place!).

The sandboxing will be toggleable with a “I know what I’m doing”-type setting that turns it off; it will still allow AJAX and full use of Obsidian/Dataview APIs, it just blocks node library requires() by default.

The README notice is a good idea - I will add that as a disclaimer in the README.