[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Possibly insecure permissions on sshd_config in Debian-based distros
From:       Kurt Seifried <kseifried () redhat ! com>
Date:       2013-08-23 0:26:01
Message-ID: 5216AC19.80309 () redhat ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/22/2013 03:07 PM, Daniel Kahn Gillmor wrote:
> On 08/22/2013 04:36 PM, Andrey Korolyov wrote:
>> On Fri, Aug 23, 2013 at 12:20 AM, Kurt Seifried
>> <kseifried@redhat.com> wrote:
> 
>>> Well the default file config would of course be known. I'm
>>> reading the man page and nothing super secret pops out, e.g. no
>>> passwords get embedded. Can you give an example of sensitive
>>> information in sshd_config?
>> 
>> AllowUsers/AllowGroups/PermitEmptyPasswords
>> 
>> Obtaining such information can shorten time of bruteforce remote
>> attacks.
> 
> I don't think these rise to the level of being worth hiding at
> all.
> 
> PermitEmptyPasswords is one additional password to test against
> each user account, which i don't think is significant.  And a user
> with local access to the machine can already radically shorten
> bruteforce enumeration of possible accounts with just with "getent
> passwd".  the gap from there to AllowUsers isn't particularly
> significant by comparison.
> 
> I don't know of any history of any serious high-entropy secrets 
> (passphrases, secret keys, etc) being stored in sshd_config, and i
> would imagine the ssh developers would resist any configuration
> that encourages that sort of thing.
> 
> Having your config files world-readable by default eases debugging,
> and can communicate to savvy users what your policies are without
> needing to exchange e-mail or chat.
> 
> Administrators who want to make that tradeoff are free to make it,
> of course, but if a proposal was made within debian to do something
> like "chmod go-r sshd_config",  i would object to it.
> 
> This doesn't warrant a CVE.
> 
> --dkg

Yup, the information would help a bit, but not enough to warrant a CVE
I think. Unless someone comes up with something new for this no CVE.



- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSFqwZAAoJEBYNRVNeJnmTqxQQAJuvFkRfb6jdL4uds9iEkUC+
vOrG/Onic46gmDnecjW6xMljLgemT3DAOJhq753QZJvFQH49wnXcf1DgdXxpXbDH
82DleaQU/oUUyswV/whOdTwqsLiWpoAQ9occ32RZWBseLyzmXJelRnlcT1ba/aNM
azrAUoLAFQLLBQFkRi0GawcTSVRzzZtJn5CWcHuigzsyc0YKYSKcJhK5q2L8cQuQ
7oXAcvg3OJBOGNDybUajhR1E/PF2aSJ8CiGGZZSrOzEB2h2FkaBzD+/Pbdp/ndq7
u0aG90E9MusOMRxVeMMWzVKq6FAAqMhS+IS/qwGX7tdcjwFMzGXM6J5H1mgaTbPY
ctKH6s1Uz37PilHQITpGUfoI0UK6WAz6cK52uw5GFxWYMh+ZBeeHOFScHnmWXKwH
vhZp6e4AdXzR3Ey9D8ts+ZAgpvc+1t57PEk1+k1bGDwiKkQmmqha8jn9dgrM1wPr
/1Hcm62VPeUblLjevbhH/z2VXr7lzk0V9LdRjU5oDGeCN0lMrHoUpTGT061URUQk
GzdFnn0QWtH9LxUYcKJ0693IndWq7AiCBLQtNtdp/+1V05N1y4SnMVrOPiDsQV0I
fWOHCbnO5+1YtDDpZNhEJWXe8rhNRYs9aQ0RfqTNKD3xn5bYTj1lPQcWKflTvqYq
jGg5+tp9EV2Da6wL66/4
=/Yx9
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]