savannah-hackers-public
[Top][All Lists]
Advanced

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

[Savannah-hackers-public] Savannah non-gnu download area policy for scp,


From: Bob Proulx
Subject: [Savannah-hackers-public] Savannah non-gnu download area policy for scp, sftp, rsync
Date: Thu, 18 Aug 2022 16:36:30 -0600

Savannah Hackers,

bill-auger helped me debug the upload issue reported in
https://savannah.nongnu.org/support/?110690 today.

The root cause of this problem is users who have upgraded their system
to OpenSSH 9.0 and the upstream OpenSSH at 9.0 has switched the
internal protocol of scp from the legacy (and problematic) scp/rcp
protocol to using sftp internally instead.  This is actually a very
good upgrade and I welcome it but the result was that it switched the
protocol to one that has been blocked due to a security concern.

    https://www.openssh.com/txt/release-9.0

    This release switches scp(1) from using the legacy scp/rcp protocol
    to using the SFTP protocol by default.
    ...
    In case of incompatibility, the scp(1) client may be instructed to use
    the legacy scp/rcp using the -O flag.

Just for completeness I will say that OpenSSH provides the scp -O
option to use the previous now obsolete scp protocol.  That would have
forced use of the old scp protocol and worked.  Until even that became
obsolete and removed.  But it is not needed because I reviewed the
issue with sftp and believe it is not a problem for Savannah due to
the special nature of Savannah only hosting Free Software and nothing
more.  Therefore I enabled sftp access.

In 2016 Sylvain Beucler reported a security issue with use of the sftp
protocol such that members may access as themselves the raw file
system.  On other systems that would be a problem of information
leakage.  But on Savannah all of the files are accessible from the
public side of things already.  There isn't anything visible from this
information leakage hack that isn't already visible by other means.
This is not an anonymous access but an access possible by project
members with commit access only.  And note that standard Unix file
system permissions prevent access to sensitive files such as to the
local encoded passwords in /etc/shadow which are not accessible to
non-root non-superuser users regardless.  They would only have access
as themselves and their project groups.  All accessible information is
already publicly accessible.

Therefore I have enabled the sftp protocol again regardless of the
possible leakage of already public information to members.

    download: /etc/membersh-conf.pl
    -$use_sftp = '0';
    +$use_sftp = '1';

I have updated the documentation for the scp and rsync commands.

https://savannah.nongnu.org/maintenance/DownloadArea/

Note that when using rsync do not use the -a option, for other reasons
unrelated to this report that attempts a chown operation which is
blocked and results in a hang and failure.  Using -t and letting owner
and group default is sufficient.

Does anyone have any reason to do something different from the above?
Although I took this action without discussion that doesn't mean that
I might be wrong.  In which case we will need to react and do
something different.

Bob

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]