On 10/01/12 13:34, Bennett Haselton wrote:
> On 1/10/2012 5:16 AM, John Doe wrote:
>> From: Bennett Haselton<bennett@xxxxxxxxxxxxx>
>>
>>> 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@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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
