lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALx_OUBWy-dCUwuop5gMTpVvdyXAi1YOR8TBPcMTAYprTikZaw@mail.gmail.com> Date: Sat, 10 Nov 2012 09:06:34 -0800 From: Michal Zalewski <lcamtuf@...edump.cx> To: halfdog <me@...fdog.net> Cc: full-disclosure@...ts.grok.org.uk Subject: Re: TTY handling when executing code in lower-privileged context (su, virt containers) > "Using su to execute commands as an untrusted user from an interactive > shell may allow the untrusted user to escalate privileges to the user > running the shell." If you have the ability to execute code on that terminal before the user executes su, it is also possible to simply never allow the real su application to run until you've already captured the credentials and escalated to root. For example, you could define an alias or change PATH in the shell; ptrace the shell or use LD_PRELOAD to change its semantics; or simply never return to the shell at all, and simply fake all the subsequent interactions with it (not particularly hard to do this in a convincing way). This is why I find the standard security mantra of "disable root logins and use su / sudo" to be extremely silly. In general, very few OSes are designed to handle such scenarios gracefully. /mz _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists