6 ms·

I've always considered root escalations to be pretty minor because you can just launch a phishing attack by adding the following to the user's .bashrc. ali

I've always considered root escalations to be pretty minor because you can just launch a phishing attack by adding the following to the user's .bashrc. alias sudo='sudo ./badscript; sudo' Most Linux/Mac installations are single user anyway, so you can steal the user's private information without even gaining root.

dooglius 7y ago
Doesn't seem like a viable threat model--a user can edit the .bashrc of a sudo-enabled user but isn't sudo-enabled himself?
- vortico 7y ago
  Running sudo requires the user password, which a script might not know. Unless of course sudo is configured with NOPASSWD.
  - loeg 7y ago
    This alias just prompts the user twice, as if the user made a typo the first time. Unless you know you're a perfect typist, it's somewhat subtle.
    - NieDzejkob 7y ago
      Not even that, because sudo keeps your password in memory for a few minutes.
    - vortico 7y ago
      Not if you have a sudo timeout enabled. Or, the proof of concept could be changed to alias sudo='sudo ./badscript' where badscript runs `exec $@`.
      - loeg 7y ago
        Good considerations. Thanks.
- dmurray 7y ago
  To use sudo normally requires the user's password; to edit bashrc does not. So yes, this is a trivial privilege escalation mechanism of a sort. It does require though that the user both is allowed to run an interactive shell with sudo, and actually does so, since you have to wait for him to run sudo in bash.
- mclehman 7y ago
  Reminding people that this is a viable threat model is why sudolph.in exists, albeit for the drive-by someone-left-their-laptop-unlocked case rather than regular local privilege escalation. I should probably add a check for catching someone within the sudo timeout and give them a hard time if so.
sigotirandolas 7y ago
The threat here is if a non-interactive non-root user (e.g. one used for a service like Apache's httpd) is pwned by another means and then this is used to further escalate to root. Otherwise you're right, despite much cargo cult, in practice pwning an user that can interactively run as root, is the same as pwning root.
loeg 7y ago
That's true for your local machine, and I think it's a reasonable threat model for that. If you do development for servers, though, (1) multiuser systems do exist where no or most users do not have sudo access, and (2) privilege separation accounts (such as www for httpd) generally do not run interactive shells. If you can escalate from an untrusted user on a multiuser system or from a non-interactive shell account to root, that's a problem. Dropping this alias won't help you on either of these kinds of system, which are important real world scenarios (but maybe not a scenario you need to care about personally).

dooglius 7y ago

Doesn't seem like a viable threat model--a user can edit the .bashrc of a sudo-enabled user but isn't sudo-enabled himself?

vortico 7y ago
Running sudo requires the user password, which a script might not know. Unless of course sudo is configured with NOPASSWD.
- loeg 7y ago
  This alias just prompts the user twice, as if the user made a typo the first time. Unless you know you're a perfect typist, it's somewhat subtle.
  - NieDzejkob 7y ago
    Not even that, because sudo keeps your password in memory for a few minutes.
  - vortico 7y ago
    Not if you have a sudo timeout enabled. Or, the proof of concept could be changed to alias sudo='sudo ./badscript' where badscript runs `exec $@`.
    - loeg 7y ago
      Good considerations. Thanks.
dmurray 7y ago
To use sudo normally requires the user's password; to edit bashrc does not. So yes, this is a trivial privilege escalation mechanism of a sort. It does require though that the user both is allowed to run an interactive shell with sudo, and actually does so, since you have to wait for him to run sudo in bash.
mclehman 7y ago
Reminding people that this is a viable threat model is why sudolph.in exists, albeit for the drive-by someone-left-their-laptop-unlocked case rather than regular local privilege escalation. I should probably add a check for catching someone within the sudo timeout and give them a hard time if so.

sigotirandolas 7y ago

The threat here is if a non-interactive non-root user (e.g. one used for a service like Apache's httpd) is pwned by another means and then this is used to further escalate to root. Otherwise you're right, despite much cargo cult, in practice pwning an user that can interactively run as root, is the same as pwning root.

loeg 7y ago

That's true for your local machine, and I think it's a reasonable threat model for that. If you do development for servers, though, (1) multiuser systems do exist where no or most users do not have sudo access, and (2) privilege separation accounts (such as www for httpd) generally do not run interactive shells. If you can escalate from an untrusted user on a multiuser system or from a non-interactive shell account to root, that's a problem. Dropping this alias won't help you on either of these kinds of system, which are important real world scenarios (but maybe not a scenario you need to care about personally).