On 03/14/2017 11:30 PM, sm8ax1 wrote:
Second, you mention that ~/.bin/sudo could be overwritten with the attacker's binary or a script. I'm not sure I understand what you mean exactly... the real sudo works by virtue of being owned by root with suid. An attacker running as user cannot create a file owned by root, so neither the real sudo nor a fake one could elevate privileges. If you mean that `sudo` could be aliased to something else, I'm not sure what that would accomplish; the underlying command would still run as the invoking user. I'm just not quite getting what you're saying.
By changing the order of $PATH paths or adding an alias in .bashrc a regular user process can impersonate the sudo and su (and other) commands so their version will run and ask for authorization whenever you do 'sudo somecommand' instead of '/usr/bin/sudo somecommand' (the latter would not be vulnerable). It will look normal and 'somecommand' will run, but attacker can piggyback his own commands to execute as root also.
(This is an old issue, resembling the way attacks could be carried out in Xwindows like clipboard sniffing, etc. and was ignored.)
Without ability to write shell init scripts, attacker can only change aliases or $PATH (or $LD_PRELOAD) for his own processes, but not for the shells or apps you started yourself.
Setting the shell startup files to immutable is a good idea I hadn't thought of. Actually I think setting them to root:root mode 755 would be sufficient, wouldn't it? That would make it one step easier to modify them as needed.
Not sufficient because 'user' still owns that dir, so it can delete those files even if they're root. Then attacker can write their own version. Solution needs +i to prevent replacement in a user-owned dir.
Going the other way--using only +i and not root ownership--should work but I was trying to be thorough. In practice user will probably modify script as root after using 'sudo chattr' so convenience-wise it doesn't matter.
-- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ff1784df-b7e4-4f78-55ef-d2f72ee71dc5%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
