newsNews: IMPORTANT: Information Regarding Savannah Restoration for All Users

 
 
Latest News
Savannah VCS Storage Maintenance Completed posted by rwp, Wed 14 May 2014 10:19:51 PM UTC - 0 replies
Savannah VCS Maintenance posted by rwp, Sun 11 May 2014 08:05:38 PM UTC - 0 replies
Savannah https SSL Certificates Updated posted by rwp, Thu 06 Mar 2014 09:11:43 AM UTC - 0 replies
Bazaar upgraded posted by mjflick, Tue 22 May 2012 02:49:11 AM UTC - 0 replies
git / cgit updated posted by mjflick, Fri 09 Dec 2011 12:13:52 AM UTC - 0 replies
[174 news in archive]

IMPORTANT: Information Regarding Savannah Restoration for All Users

Item posted by Bradley M. Kuhn <bkuhn> on Tue 23 Dec 2003 12:45:26 PM UTC.

As you know, savannah.gnu.org and savannah.nongnu.org have been down for a
number of weeks due to a system crack. Thanks to the contributions of
many people -- most notably Mathieu Roy, Jim Blair, and Paul Fisher -- the
system is working again for existing projects.

We have implemented a new security infrastructure that uses chroot'ed
environments to isolate each project. We have of course tightened up
security, but even if that tightened security is compromised for a
particular project, the cracker can most likely only impact that one
project. Please read this whole statement in detail before beginning work
again.

As part of the security changes, there are nine user-visible changes of
particular interest. Six of those changes are implemented now (three of
which are temporary), and two will be implemented later. They are as
follows:

(0) All passwords were invalidated. You will need use the "Lost
Password" option to regain access. (Click on "Login via SSL" and
then the "[Lost Password?]" link.) Expect an email shortly once
you've clicked that link. If you do not receive the email within a
very short time period to the address you had on file with your
account, please write to <savannah-compromise@gnu.org>.

Once you have access again, please check the developer and
administrator lists for all your projects, and be sure that you
recognize all the email addresses and user accounts attached to
your projects. It is up to each user to vigilantly check the other
authorized users, just as it was to check the integrity of your
source.

(1) All authorized SSH keys have been removed from the database. Once
your account is reactivated, you must again upload your SSH key.
We now only accept SSHv2 keys. Although the web interface will
allow you to upload SSHv1 keys, they will not function to give you
access. Only SSHv2 keys will provide access and savannah will only
accept SSHv2 connections.

(2) Anonymous CVS access will continue, but pserver access has been
discontinued. We realize that many have become accustomed to this
form of anonymous access, but we found many security problems in
pserver and we must avoid it. Anonymous access can now occur via
SSHv2. To do so, use the following CVSROOT:

:ext:anoncvs@savannah.gnu.org:/cvsroot/PROJECT
or
:ext:anoncvs@savannah.nongnu.org:/cvsroot/PROJECT

So, for example, to get an anonymous checkout of the GNU Emacs
sources, you would run the following on the bash command line:

export CVS_RSH="ssh"
cvs -d :ext:anoncvs@savannah.gnu.org:/cvsroot/emacs co emacs

The first time you do this, you will be prompted by SSH to
authenticate the server's key fingerprint. See (3) below for
details.

Note that since only SSHv2 is accepted, you must be sure that your
~/.ssh/config does indicate use of "Protocol 1" with
savannah.gnu.org and savannah.nongnu.org.

If you are absolutely unable to use this method for anonymous
access, and you rely on anonymous access, please contact
<savannah-compromise@gnu.org>. Since SSH is now ubiquitously
available on Free Software systems, we believe that requiring SSH
to be installed locally to gain anonymous access from savannah is
not burdensome. If it turns out to burden you, please contact us.

In fact, this new method authenticates and secures all anonymous
access, and anonymous users are now safe from person-in-the-middle
attacks when they verify the SSH host keys.

(3) The host SSH keys for savannah.gnu.org, savannah.nongnu.org,
subversions.gnu.org, etc. have changed. They are as follows:

DSA 1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5
RSA 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5

You will prompted for these the first time you use SSH to connect.
If you have older keys stored in your known_hosts file, you may get
a message that says there is a "nasty problem". If so, remove the
offending entry from your ~/.ssh/known_hosts, and reconnect. SSH
will prompt you to authenticate anew with one of the keys above.

(4) Temporarily, we are unable to approve new projects on savannah. We
expect to begin accepting new projects before the end of January
2004. We have to reimplement project creation scripts to adhere to
the new chroot structure.

(5) Temporarily, the file distribution areas for releases are not
functioning. We hope to make them functional again in January 2004
and secure them by using a similar system to that now used on
ftp.gnu.org.

(6) Temporarily, all web CVS trees are not functioning. It is
currently not possible to work on the CVS trees for websites using
savannah. We hope to fix this in mid-January 2004.

(7) In early January 2004, we will record for each project whether or
not the developers have checked their integrity using the data in
previously-posted announcements. The indicator will be similar to
the "is GNU"/"is not GNU" indicator on the main project page.

(8) You will later be required to upload a GnuPG key. We are working
on changes that will require GPG-signing of all CVS commits. That
functionality is not yet available, but when it is, we plan to
make it mandatory to ensure the integrity of all software hosted
on Savannah.

Finally, I want to thank all of your for your patience while we worked to
resolve these problems. I know that many of you have been considering for
the past few weeks switching to another project development site. I don't
blame you for considering that. However, I ask now that you decide to
stay. We have learned from this experience how to harden the system to be
less susceptible to cracking, and the changes we've made will not only
help to prevent future cracks, but will mitigate the damage such a crack
can cause. The GPG-signing features that we plan to add in the coming
months will (at least at first) be unique among project hosting sites, and
ensure the integrity of your software to the greatest degree that is
humanly possible.

Meanwhile, Loic Dachary has coordinated the acquisition of new, redundant
servers in France, and we will work over the coming months to make them
(at first) read-only mirrors of the existing savannah (that can be turned
immediately live upon the occurrence of the crack). In addition, as
Executive Director of FSF, I am committed to implementing protocols and
procedures over the next few months designed to limit downtime to a matter
of hours in the case of a crack.

This crack comes on the heels of cracks against many other Free Software
project sites; the crack of savannah is not an isolated incident. We must
work together as a community to weather these incidents. For our part,
this meant long hours and late nights over the past weeks to harden the
system, and more hard work to improve our disaster recovery plans. We ask
that you make a contribution by sticking with us now that we've hardened
the system and work with us to keep the system secure for Free development
and software sharing.

Sincerely,

Bradley M. Kuhn
Executive Director, Free Software Foundation
Monday 22 December 2003, 19:51 EST

A GPG-signed text file of this statement is available at:

http://savannah.gnu.org/statements/savannah-restored.txt.asc

Comments:

Too complex ? (posted by Dany De Bontridder, Thu 08 Jan 2004 08:47:32 AM UTC)

I'm wondering if the complexity of the security rules will not discourage new members to come here ?

New members are also contributors and all of us need them, if they would like to help a project but are afraid by the security policy, they could change their mind and it is not fun to lose or to don't have contributors.

Even the simple documentation writer has to learn first the use of ssh and gnuPg and cvs.


Thanks to the team (posted by Ric, Wed 24 Dec 2003 09:35:39 PM UTC)

After the incident ..i was wondering if we'd ever see Savannah up again.
The team has worked hard, and the rewards are also high.
Renewed user confidence in the software is top on the list.
Now that the site's security is beefed up we , the end users can
now rest and be assured of this site's commitment to have good
safe software.
The fact it has been cracked is nothing in itself.The fact the team got
to work and fixed, beefed up and checked the software is in itself
the event here.
That's the real event id like people to focus on.
Savannah is renewed, beefed up and more than ever before
a trustworthy source of quality and important software for the
community.
Congratulations to everyone who worked at it and that day by day
make this a better place :)

Richard Hebert
aka FuzzyTheBear


The FSF stand on security features in GNU? (posted by B Galliart, Wed 24 Dec 2003 06:57:12 PM UTC)

GNU coreutils v5.0 still contains in doc/coreutils.texi a statement as to why GNU su should never impliment the "wheel" group. It uses the example of the MIT AI lab in which the masses that had access to the lab had a stake in using any administrative privilages constructively. The story goes that RMS patched the Twenex system kernel to give power back to the masses.

It is my understanding that administrative power of Savannah was taken by the masses via a bug in brk() which effectively allowed the kernel to be "patched" similar to RMS' patch of Twenex. But the responce to this act seems to be an acknowledgement that not all the masses have a stake in using administrative privilages constructively. Rather, Savannah was taken down to reduce any destructively administration that could have occured. And finally, as stated above, it was decided to make use of chroot to reduce the chance of re-occurence. But to some degree, isn't chroot being used as a method of implimenting the goals of the wheel group (and then some)? The effect is that members outside of a specific group are placed in a restricted enviroment such that even when provided the administrative password they are not permitted access to su.

While I'm far from being "used to supporting the bosses and sysadmins in whatever they do," I think their actions tend to be less destructive that openning administrative access to the masses of the Internet. As GNU systems continue to be targetted for use on the Internet, virtual restrictions are needed to gain back what used to be provided by physical restrictions--namely that those that do gain administrative access have a stake in using it constructively. I ask that the FSF re-evaluate the stance stated in the GNU coreutils documentation and eventually allow patches which impliment security measures such as the "wheel" group to be part of the GNU system.


SSH Version 2 Keys used (posted by Paca, Tue 23 Dec 2003 12:32:10 PM UTC)

"Note that since only SSHv2 is accepted, you must be sure that your
~/.ssh/config does indicate use of "Protocol 1" with
savannah.gnu.org and savannah.nongnu.org. "

why should ~/.ssh/config indicate "Protocol 1"
if SSH version 2 is used ?

Best regards


Missing negation (nitpicking) (posted by Mathieu Lacam, Tue 23 Dec 2003 10:54:12 AM UTC)

In section (2), s/does indicate "Protocol 1"/does not indicate "Protocol 1"/

Sorry for the nitpicking...


   

 

Back to the top


Powered by Savane 3.1-cleanup