←back to thread

Less is safer: How Obsidian reduces the risk of supply chain attacks

(obsidian.md)
429 points saeedesmaili | 4 comments | 19 Sep 25 22:02 UTC | HN request time: 0s | source
Show context
gejose ◴[19 Sep 25 23:42 UTC] No.45308131[source]▶
This is one way to look at it, but ignores the fact that most users use third party community plugins.

Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.

Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.

Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.

Both of these approaches would've led to more real security to end users than "we have few third party dependencies".

replies(19): >>45308149 #>>45308208 #>>45308212 #>>45308222 #>>45308224 #>>45308241 #>>45308572 #>>45308600 #>>45308749 #>>45310219 #>>45310642 #>>45310881 #>>45310991 #>>45311185 #>>45311760 #>>45311782 #>>45312975 #>>45313054 #>>45314194 #
0cf8612b2e1e ◴[19 Sep 25 23:45 UTC] No.45308149[source]▶
Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.
replies(6): >>45308244 #>>45308310 #>>45308373 #>>45308539 #>>45309613 #>>45310771 #
jabbany ◴[19 Sep 25 23:55 UTC] No.45308244[source]▶
Browser extensions also have a relatively robust permissions-based system.

If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.

replies(2): >>45308286 #>>45312257 #
0cf8612b2e1e ◴[20 Sep 25 00:02 UTC] No.45308286[source]▶
I would have thought, but it has been how many years, and as far as I know, there is still no segregation for VSCode extensions. Microsoft has all the money and if they cannot be bothered, not encouraged that smaller applications will be able to iron out the details.
replies(1): >>45308319 #
1. jabbany ◴[20 Sep 25 00:07 UTC] No.45308319[source]▶
I think it's just because supply-chain attacks are not common enough / their attack surfaces not large enough to be worth the dev time... yet...

Sneak in a malicious browser extension that breaks the permissions sandbox, and you have hundreds of thousands to millions of users as an attack surface.

Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs...

replies(3): >>45309290 #>>45311372 #>>45311771 #
2. connicpu ◴[20 Sep 25 01:49 UTC] No.45309290[source]▶
The solution at my job is you can only install extensions vetted by IT and updates are significantly delayed. Works well enough but sucks if you want one that isn't available inside the firewall.
3. anon7000 ◴[20 Sep 25 07:54 UTC] No.45311372[source]▶
The time has come. The nx supply chain attack a couple weeks ago literally exfiltrated admin tokens from your local dev machine because the VS code extension for nx always downloaded the latest version of nx from npm. And since nx is a monoreop tool, it’s more applicable to larger projects with more valuable tokens to steal.
4. fauigerzigerk ◴[20 Sep 25 09:27 UTC] No.45311771[source]▶
>Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs..

Attackers just have to hit one dev with commit rights to an app or library that gets distributed to millions of users. Devs are multipliers.