3 ms·
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?
by 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 agoRunning sudo requires the user password, which a script might not know. Unless of course sudo is configured with NOPASSWD.
- loeg 7y agoThis 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 agoNot even that, because sudo keeps your password in memory for a few minutes.
- vortico 7y agoNot 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 agoGood considerations. Thanks.
- dmurray 7y agoTo 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 agoReminding 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.