Jumping sudo using ptraceFor many years now I've been making the claim that one can use the ptrace api to intecept the execution of sudo of another process (running as the same user) and replace the requested command with your own. For example, if a user was to do: sudo apt-get install foo Password: ... they are instructing sudo to run apt-get, but an attacker can use the ptrace api to insert a new argument before apt-get which invokes their own program, which might do something malicious and then execute the original command requested of the user. This could be useful to an attacker in a number situations. For example, if the attacker has aquired access to a given account and notes that the account owner execute sudo, he can use this technique to escalate his privileges. Perhaps more importantly, however, is that a trojan or a virus can use this technique to get root whereby its capability is greatly increased. Similar attacks can be directed at su and other suid/sgid programs. All of this is most likely not very much of a surprise to the security community, and I shall not present any possible remedy, except to say that ptrace is necessarily a very capable api and should not be implicated as "the" cause of this potential insecurity. My purpose of writing this post is to provide demonstration code that, I hope, will clarify any misunderstandings about the potiential of this technique, and move it from the often ignored domain of theoretical to practical threat so that it may be suitably addressed. QuantumG ----------------- usage: sudojump [-d] [-v] [-h] << back to my home page tuxhelper.info says: Has this been addressed or overlooked ?? QuantumG says: It's been largely overlooked. This is an example failing of the UNIX security model. Programs are run by users and it is assumed they should have all the privileges of the user. When presented with a problem involving a malicious program the UNIX security model response is "run it as another user" which, of course, is absurd. defcon says: nice work, "./sudojump -d 31337 sh" works well hehe Harry says: Hi, What date did you post this? I like the code - have modifyed it slightly but am wondering how 'old' this issue is? Thanks thirdwheel says: Just tried it in Debian Etch x86... works :O Tried in Debian Lenny x64... refused to compile. Looks like it's x86 specific. I'll have to set up a lenny-based x86 system to check this out. thirdwheel says: Ok, just did a quick test - the best way to limit the scope of this is to not give users full access, but access only to the things they need. Never ever give access to a shell, only the tools that the user is likely to use. Very easy to do in the sudoers file. Anybody who gives users full superuser access in any way should not be allowed near a server, or a computer for that matter. |