4 ms·

> I always use sudo to manage the few docker containers I need I'm afraid that isn't really any better. If the attacker is in position to exploit membership in

> I always use sudo to manage the few docker containers I need I'm afraid that isn't really any better. If the attacker is in position to exploit membership in the docker group, he already has access to the user's .bashrc. He can simply write a function called sudo that wraps the real command and records your password[1]. Unless the user always invokes sudo with /usr/bin/sudo, docker group membership doesn't really make a difference. Once malware runs as an administrator, getting access to root isn't really that complicated. The boundary between wheel and root is more or less security theater. [1] https://gist.github.com/tokyoneon/34ce1c9e1530a12eb392b1eab09fcbac#file-sudo https://gist.github.com/tokyoneon/34ce1c9e1530a12eb392b1eab0... Edit: Oh well, I see now that others have made the same point (https://news.ycombinator.com/item?id=49500588 https://news.ycombinator.com/item?id=49500588). With the same wording even. I'm half-way tempted to delete my comment so as not to look like a plagiarist, but it seems many posters are unaware of the vulnerability, so I'd leave it here.

jijijijij 17d ago
Does 'chattr +i .bashrc' reliably prevent this? Always seemed sensible to me. Then again, there are a few files getting sourced by the shell and I am not sure I could spontaneously name them all.
- mjmas 17d ago
  The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. A better way would probably be to use `sudo chown 0:0 .bashrc`. Also you will want to do the same to .profile (because of LD_PRELOAD etc). And also do the same to any directories in your $PATH (~/.local/bin etc)
  - jijijijij 17d ago
    > The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. No. Setting flags requires root privileges, sudo was implied. At least on my system. > Also you will want to do the same to .profile (because of LD_PRELOAD etc). Yeah, that's what I meant with additional files sourced by the shell. I knew about .profile, but I am not sure that's all of it. I think different distros may be set up differently in this regard. Also I am pretty sure, you can define function overwrites/aliases and execute code in any file getting sourced, it's not just LD_PRELOAD attacks.

jijijijij 17d ago

Does 'chattr +i .bashrc' reliably prevent this? Always seemed sensible to me. Then again, there are a few files getting sourced by the shell and I am not sure I could spontaneously name them all.

mjmas 17d ago
The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. A better way would probably be to use `sudo chown 0:0 .bashrc`. Also you will want to do the same to .profile (because of LD_PRELOAD etc). And also do the same to any directories in your $PATH (~/.local/bin etc)
- jijijijij 17d ago
  > The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. No. Setting flags requires root privileges, sudo was implied. At least on my system. > Also you will want to do the same to .profile (because of LD_PRELOAD etc). Yeah, that's what I meant with additional files sourced by the shell. I knew about .profile, but I am not sure that's all of it. I think different distros may be set up differently in this regard. Also I am pretty sure, you can define function overwrites/aliases and execute code in any file getting sourced, it's not just LD_PRELOAD attacks.