[OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos

[Dean Anderson]

On Tue, 3 Feb 2004, Damien Miller wrote:

> On Mon, 2 Feb 2004, Dean Anderson wrote:
> 
> > This doesn't mean the privsep prevented an exploit. If it segfaulted, a 
> > little more fuzzing can get shell code to run.  After that, you have at 
> > least non-root access, and you have sockets to the privsep processes that 
> > have root privilege.
> > 
> > We know how to escalate non-root processes to root.
> > 
> > So, the privsep didn't protect anything.  
> 
> Get real.
> 
> My deadbolt door locks don't stop thieves who smash windows, by your 
> logic they "don't protect anything" either.

That wasn't my logic, but it makes no sense to put a deadbolt lock in a
glass door.  Nor will adding a second glass door improve your security.  

Basically, privsep is a second glass door.  You have to exploit the
non-privileged part, and then you have a choice to either exploit the
privileged part, or use another method to escalate to root.  No security
improvement, just a gratuitous change that will break old exploit code
that assumed it had root right away.

> There is a world of difference between a break in a process running with 
> root privileges and a break in an unprivileged, chrooted process. It seems 
> that this value is self-evident to everyone but you.

First, this is a loose, general principle. Sure, it is a good idea to
remove privileges when a process doesn't need root privileges.  But, the
process that creates new user connections does need root privileges. It is
a fundamental rule that you can't remove privileges that are necessary.  
You seem to have seized on the idea of privilege removal and have taken it
to the extreme, mistakenly believing that you could obtain more security
somehow.

Second, there isn't much difference between a non-root breakin and a root
breakin. You have to react the same way to both: You don't know if they
didn't get root, or they did and you simply haven't found evidence of a
root breakin. Perhaps they were very good about cleaning up their root 
activity, but lazy with their non-root crack.

Privsep hasn't changed anything, but it added more (exploitable)  
complication. Not to mention that it broke a great many things. If the
non-privileged openssh process is exploitable, then probably so are the
"privsep" parts, since the lower privilege part still has sockets to the
root parts.  You haven't changed anything, even if there weren't easy ways
to escalate to root. If you can't write code that isn't subject to stack
overflow, etc, then your privsep scheme isn't going to fix that.  
Basically, you just broke a bunch of stuff, and called it a security
enhancement.

Getting old rootkit exploits to fail doesn't indicate improved security.  
You can do that in a number of other ways, which also don't change the
security of the program, and could in fact reduce the security.  For
example, offering an immediate root shell to any connection will also
cause the exploit code to fail, but doesn't improve security.

> Anyway, you are more than welcome to make your forked version which 
> removes security features, but please stop trolling on our lists.

Anyway, I didn't join your list. This discussion is from another list
(openafs-devel), where we were discussing openssh brokenness with respect
to obtaining afs credentials. Someone (not me) added the openssh list to
the distribution.  I didn't expect to convince you of the wrongness of
your ways, either--I've looked at the code enough to know there couldn't
be any cooperation. Its not just privsep.  This is why we need a forked
version.  Sorry.

		--Dean