Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A rogue npm package is my nightmare scenario, those packages are like the only (or I wish..) untrusted code my OS is running.

That's why I came up with a small script/service waiting for an "inotify" event on a honey-pot SSH key (and some other files like ~/passwords.doc) which will immediately shutdown the computer on any kind of access of those files.

    #!/bin/sh

    inotifywait -e open --fromfile ~/.config/killer/killer.cfg --outfile ~/.config/killer/killer.log

    if [ $? -eq 0 ]; then
        poweroff
    fi


This is a neat idea. Though in my case an accidental grep through my homedir would be incredibly annoying.


Run untrusted stuff in a VM/container.


How does that solve an accidental grep that touches a file being monitored? Grep and your key are both trusted, and there are numerous ways someone can try to read the key despite only running specific things in a vm (and forgetting that VMs aren't bulletproof)


mac "containers" run in virtual box with exposed paths, which is vulnerable to symlinks attacks and others


I fear this might be too slow to stop an automated attack. Passing -f to poweroff, so that shutdown(8) is not called, might help a bit.


You could also just down your network interfaces.


Don't forget about ransomware. Imagine the rogue package encrypted your files and demanded payment to get the decryption key. With public key encryption or a symmetric key that is securely deleted, there is no need for network access for the attack to succeed. A fast shutdown could protect most of your files.

https://en.m.wikipedia.org/wiki/CryptoLocker

Although I think the best way to deal with ransomware is a strong backup policy, not a tripwire shutdown trick.



Good point. I haven’t thought about it much since I’m on macOS and Linux but it’s not like they’re immune. The idea of a node module encrypting my home directory (even with backups) makes me a tad nervous.


"Are you sure you want to quit? iTerm2 is still open."


You don't have to run untrusted npm packages for development. I do all of my development on development servers and just sync over node_modules for IDE autocompletion.


Agreed, I don't have to, old habits die hard.

I guess I will just set up a development VM (as @pas suggested) instead of remote development though, so thank you to both of you.


And how can you tell if that was the source of your power off?


By examining the timestamp on the log file (defined by the --outfile parameter).


Powering off will destroy valuable evidence, though, most payloads live in-memory nowadays. Maybe just disable the NIC?

It's not going to do much against a determined adversary, anyway. If he's prepared to turn the NIC back on, he would just kill your inotifywatch first.


Honestly, I didn't give it any serious thought, I came up with the idea and quickly executed it as a PoC in a couple of minutes after that compromised npm package incident a while ago.

Disabling the NIC is a nice idea too, it should also be much quicker than shutting the machine down, so, please, feel free to make the script better.

The only "clever" thing I did was making sure the honey-pot key comes first in the ~/.ssh directory and that it's big (to gain time to poweroff while it's being transmitted to somewhere).

Clearly, this is not a protection against a determined adversary.


I am not familiar with Node or npm. Is there something specific to Node's package system that requires running untrusted code?


Not really. A lot of other package managers are vulnerable to the same kind of attacks seen on node/npm.

It's just that a lot of npm packages can have an excessively long dependency chain which make it harder to audit. And the npm ecosystem is massive.


Not really. Most dependencies get RCE one way or another, just not necessarily at installation.


Sorry what is RCE?


My bad: remote code execution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: