On 10/01/12 13:34, Bennett Haselton wrote: > On 1/10/2012 5:16 AM, John Doe wrote: >> From: Bennett Haselton<bennett at peacefire.org> >> >>> On 1/10/2012 2:02 AM, Adrian Sevcenco wrote: >>>> 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''. >>> OK. So it sounds like if you found a particular exploit in sshd that >>> could *only* do certain things -- like write a file to an arbitrary >>> location on disk -- then this privilege separation would prevent that >>> exploit from being used to make the child process write somewhere that >>> it didn't have privileges to write to. >> Do a ps and look at the sshd tree. Example: >> root 6014 0.0 0.1 97816 3760 ? S 11:01 0:00 \_ sshd: bob [priv] >> bob 6029 0.0 0.0 97816 1796 ? S 11:01 0:00 \_ sshd: bob at pts/2 >> bob 6030 0.0 0.0 108392 1760 pts/2 Ss 11:01 0:00 \_ -bash >> >> The sshd child is running as bob; so it has bob (and not root) rights... >> >> JD > > Yes, I understand that. What I said was that if you could take complete > control of the sshd process you were connecting to, even if that process > was completely unprivileged, you could still make it say "Accept a login > from 'root' with password 'foo'" and then log in as root. > Probably. If a flaw were to exist in OpenSSH that allows execution of arbitrary code then pretty much anything is possible, which is why it is wise to always stay fully patched and limit exposure by only providing access (to the sshd service) to those that need it. Heck, even security through obscurity (running on a non-standard port) will limit exposure to the extent that the casual attacker scanning for machines vulnerable to a zero-day vulnerability will probably pass you by given the number of lower hanging fruit out there. What you are talking about is essentially a zero-day vulnerability that's being actively exploited in the wild. So although you said you weren't talking about layers of security in front of sshd, these are exactly the layers of defence that will help limit the scope of such an attack. You can't look at security in isolation, you have to look at the whole picture, identify the risks in your systems and then take measures to mitigate those risks that are relevant to you. IOW, if you only access the system from a handful of locations, firewalling the sshd service to only allow access from those IP ranges essentially makes the rest of the discussion redundant. Similarly, running on a non-standard port will be highly effective against the casual attacker scanning large areas of the IP address space for vulnerable machines to attack, less so against a targeted attack.