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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAEJizbbj6wFe6UbTspiU6uYPo2yijC6Lk9u60spPGfhZiBogbg@mail.gmail.com>
Date: Sat, 10 Nov 2012 17:51:30 +0000
From: Benji <me@...ji.com>
To: Michal Zalewski <lcamtuf@...edump.cx>
Cc: Full-Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: TTY handling when executing code in
 lower-privileged context (su, virt containers)

"This is why I find the standard security mantra of "disable root
logins and use su / sudo" to be extremely silly."

I think you've taken that far too literaly. My understanding of it is to
protect against a) brute force retardation b) dumb attackers. Noone said
it's supposed to completely protect uid=0. If you're seeing that as
"extremely silly" then you're interpreting the recommendation in the wrong
way.


On Sat, Nov 10, 2012 at 5:06 PM, Michal Zalewski <lcamtuf@...edump.cx>wrote:

> > "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/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/