1

TL;DR: running npm i ... not long after pass my-password allows a malicious package to steal my entire password store.

I use pass as a password manager, on Linux. And like probably all Linux users, I use sudo to run commands as root.

The first time I retrieve a password with pass my-password, I need to type the passphrase of my GPG private key. Then, the GPG agent will keep this passphrase in memory for a few minutes.

Same with sudo: running a few consecutive sudo commands will only ask for the password once.

Now, when I install packages with npm install ... (or with Pip, or any other package manager), these packages can contain scripts that can be run.

This poses an incredibly dangerous security issue: if I run npm install ... not long after I ran pass, a malicious package could steal the entire content of my password store. Same issue with sudo. Even more incredible: it's very hard to find people on the interned who care about it.

The first solution that comes to my mind is to set the timeout for the GPG agent and sudo to 0.

Another one is to open every projects I work on in a development container (a docker container), to prevent scripts in it to access my home folder. But it would require to constantly create containers for new and existing projects, which can take quite some time.

Can you think of any other solution?

Improve this question
6
  • 1
    Once you run untrusted code, the game is pretty much up. What stops the code from waiting around until you run pass again? Or reading the keyboard input?
    – vidarlo
    Commented Jul 14, 2022 at 5:48
  • Thanks for your comment. If the timeout of the GPG agent is set to 0, then no other program should be able to get anything from pass even if they wait for me to use it. And I would have thought that a program needs root access to be able to read keyboard input in the background, but maybe that's not the case.
    – Zwyx
    Commented Jul 14, 2022 at 6:32
  • I agree with you though, the problem is with executing code coming from the internet... so NPM should always be used inside a sandboxed environment. But no one is that meticulous!
    – Zwyx
    Commented Jul 14, 2022 at 6:36
  • X11 allows all clients to read all input.
    – vidarlo
    Commented Jul 14, 2022 at 6:52
  • very hard to find people on the interned who care no, its just that you can have security or ease of access ... not both. If you are worried about random packages stealing your creds then dont have pass wordless sudo and dont use pass on that box. If you want ease of access ... then dont be worried. Only you can make this judgment call as it should be based on your threat level.
    – CaffeineAddiction
    Commented Jul 14, 2022 at 10:27

2 Answers 2

Reset to default
2

running npm i ... not long after pass my-password allows a malicious package to steal my entire password store

Yes, but not just that. Running npm i ... at any time before pass my-password allows a malicious package to steal your entire password store. A malicious package can inject code somewhere (for example the pass executable or a library that it uses) so that whenever sensitive data becomes accessible, the malicious entity will have access to it as well.

As soon as an environment is compromised, it's game over.

The only solution is to run untrusted code in an isolated environment.

(Mind you, why are you installing development packages you don't trust? Are they somehow secure enough for the users of the product you're developing, but not for yourself?)

Improve this answer
2
  • Thanks for your answer. It's true that as soon as the environment is compromised, there is not much to do to save it. To answer your question: the packages I download are going to be used in a web app. For my users, these packages will be executed in a web browser, which is a safe and sandboxed environment. For me however, these packages can simply do anything as soon as I install them.
    – Zwyx
    Commented Jul 20, 2022 at 7:10
  • So it appears to me that NPM is too open and I'm wondering why it hasn't been made more secure by default, for instance by preventing execution of scripts at install, unless explicitly authorised. But as mentioned in a comment above, it has probably been done to allows ease of usage, to the detriment of security.
    – Zwyx
    Commented Jul 20, 2022 at 7:12
0

That’s only a partial solution to your problem, but I do use a hardware token for my GPG key. Whenever the hardware token is unplugged, no malicious code can use my GPG key.

Moreover, the hardware token I am using is a Yubikey that can me configured so that it requests to be physically touched before any decryption/signature/authentication operation is performed. When configured that way, if any malicious code tries to use your key, you may notice your hardware token is blinking and it won’t perform the operation unless you touch it.

Anyway, I consider this is only in-depth protection. I fully agree with Gilles’ answer that you should better not run untrusted code in a non-isolated environment.

Improve this answer
1
  • I did consider getting one of those indeed! But I think it would be the same as having a GPG agent timeout of 0. Thanks for your answer.
    – Zwyx
    Commented Jul 20, 2022 at 7:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .