3 ms·

Ya there are some solutions, like you can prefix a '\' before a command to make sure you are running the real command and not a alias, so in your example runnin

Ya there are some solutions, like you can prefix a '\' before a command to make sure you are running the real command and not a alias, so in your example running: \sudo <command> would defeat your attack. But few are in the practice of doing that.

vortico 9y ago
Didn't know that! Thanks.
TylerE 9y ago
Would it? If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?
- seiferteric 9y ago
  Isn't the login shell set in /etc/passwd? So you would need root to either modify that, or to overwrite the shell binary.
slrz 9y ago
> But few are in the practice of doing that. Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.
- seiferteric 9y ago
  I'm sure there are plenty of tricks. I could be wrong, but I think the \ is a shell builtin thing, so I don't think creating a \sudo or the like would work. You could set the PATH and put a fake sudo in a secret directory in there that precedes the /usr/bin/sudo though, so that would be a problem.
  - shabble 9y ago
    untested, but I think you could possibly bypass it with a malicious .inputrc binding for <enter>, although making it conditional such that it only removed a leading \ could be tricky. In Bash there might also be a way to do something cunning with a 'trap DEBUG' hook to modify the command between submission and it actually being run. Or you could just exec into a terminal multiplexer like screen[1] to intercept & rewrite/suppress both commands and output. Edit: It's much easier than that. The function: echo () { command echo "hax" $@; } will still be called by '\echo test' (The 'command' prefix stops it becoming a forkbomb :) [1] or maybe just hijack stdin/out FDs from the shell?

vortico 9y ago

Didn't know that! Thanks.

TylerE 9y ago

Would it? If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?

seiferteric 9y ago
Isn't the login shell set in /etc/passwd? So you would need root to either modify that, or to overwrite the shell binary.

slrz 9y ago

> But few are in the practice of doing that. Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.

seiferteric 9y ago
I'm sure there are plenty of tricks. I could be wrong, but I think the \ is a shell builtin thing, so I don't think creating a \sudo or the like would work. You could set the PATH and put a fake sudo in a secret directory in there that precedes the /usr/bin/sudo though, so that would be a problem.
- shabble 9y ago
  untested, but I think you could possibly bypass it with a malicious .inputrc binding for <enter>, although making it conditional such that it only removed a leading \ could be tricky. In Bash there might also be a way to do something cunning with a 'trap DEBUG' hook to modify the command between submission and it actually being run. Or you could just exec into a terminal multiplexer like screen[1] to intercept & rewrite/suppress both commands and output. Edit: It's much easier than that. The function: echo () { command echo "hax" $@; } will still be called by '\echo test' (The 'command' prefix stops it becoming a forkbomb :) [1] or maybe just hijack stdin/out FDs from the shell?