CentOS - Jan 2012 - defense-in-depth possible for sshd?

If an attacker finds an exploit to take control of httpd, they're still 
blocked in part by the fact that httpd runs as the unprivileged apache 
user and hence can't write any root-owned files on the system, unless 
the attacker also knows of a second attack that lets apache escalate its 
privilege.  Basically correct?

What about sshd -- assuming that the attacker can connect to sshd at all 
(i.e. not prevented by a firewall), if they find an exploit to let them 
take control of sshd, would that imply immediate total control of the 
machine?  Because if they can control sshd they can tell sshd, "Allow 
root login (even if prohibited in sshd.conf) and accept 'foo' as the 
password", then the attacker can log in as root.  Is it possible, even 
in theory, to provide a second layer of defense behind sshd to prevent 
the attacker from controlling the machine, if the attacker controls 
sshd?  The "log me in as root" attack would appear to imply that an 
extra layer is not possible.

(Note I'm not talking about extra layers of security *in front* of sshd, 
like a firewall that only permits logins from known locations.  I'm also 
not talking about detection after the fact -- obviously you can detect 
unexpected root logins from the /var/log/secure* files if the attacker 
doesn't erase them -- only whether you could use extra layers to 
*prevent* the attacker from owning the machine if they take control of 
sshd.)

On 01/10/12 11:12, Bennett Haselton wrote:
> What about sshd -- assuming that the attacker can connect to sshd at all
> (i.e. not prevented by a firewall), if they find an exploit to let them
> take control of sshd, would that imply immediate total control of the
UsePrivilegeSeparation
Specifies whether sshd(8) separates privileges by creating an 
unprivileged child process to deal with incoming network traffic. After 
successful authentication, another process will be created that has the 
privilege of the authenticated user.  The goal of privilege separation 
is to prevent privilege escalation by containing any corruption within 
the unprivileged processes.  The default is ``yes''. If 
UsePrivilegeSeparation is set to ``sandbox'' then the pre-authentication
unprivileged process is subject to additional restrictions.

http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5

also selinux is everywhere this days... (default mechanism for 
"defense-in-depth")

HTH,
Adrian

On 01/10/2012 01:12 AM, Bennett Haselton wrote:
> What about sshd -- assuming that the attacker can connect to sshd at all
> (i.e. not prevented by a firewall), if they find an exploit to let them
> take control of sshd, would that imply immediate total control of the
> machine?
Yes, but the question itself ignores the extensive security that 
accompanies sshd.

OpenSSH's server already features defense-in-depth.

OpenSSH's server features privilege separation, a mechanism in which the 
network connections and encryption are handled by a process which is 
unprivileged.  Attacks against connection handling or encryption won't 
get you root access.

OpenSSH's server code has been thoroughly audited for security.

Red Hat's build of OpenSSH's server features an SELinux policy.  Attacks
which require system access not granted by the policy won't work.

All of Red Hat's systems feature shared lib address randomization, to 
protect against stack attacks.

Your hypothetical attack that takes control of sshd would have to defeat 
a number of levels of defense.  You compared sshd to httpd, which runs 
as a non-root user, but ignore that its *purpose* is to grant shell 
access to the system.  No matter what additional layers you add to sshd, 
a successful attack is going to grant shell access, because that's the 
purpose of the daemon.  You can't lower the privilege level of sshd to 
the point that an attacker can't get a shell (which is what was done to 
httpd) without making the service useless.