Chris Laprise: > 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.
Thanks for clarifying that. Piggybacking his own commands in addition to the argument to `sudo` is the key part I wasn't getting. The fix to that I think would be showing the command (binary path + args) in the Dom0 dialog. e.g. "my-vm" is attempting to run "/usr/bin/bash -c '/home/user/.malware.sh ; realcommand'" as root. Allow? [x] Always do this for requests from this VM in the future. [Yes] [No] [View environment variables] It might already have some of these features for all I know. I haven't tried it yet. Untrusted environment variables, if allowed by sudo (they are disallowed by default), present another problem. This could probably be solved by showing the untrusted/modified ones in the dialog as well. >> >> 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. > I don't know why I didn't catch that. I guess I have to go back to Unix 101. Immutable it is. Just a note for the record, this is an added anti-persistence feature, but it isn't required for vm-sudo to work as described. ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7a291de8-3591-4983-f27e-55b2be131ca2%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
