full-disclosure - Re: TTY handling when executing code in lower-privileged context (su, virt containers)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/