Re: defense-in-depth possible for sshd?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux