Live data from Hacker News

Main GNU source repository server compromised

savannah.gnu.org

1–10 of 47 posts

Re: Main GNU source repository server compromised

#2
I see a lot of angry comments on their webpage, people asking why somebody would do this. Well, the real answer is probably - simply because he/she could. And to all of those wondering how anybody could do this to a project that hosts free software, well, the attackers don't really care. They saw the exploit and used it. Personally, I expected that a project such as Savannah wouldn't be vulnerable to an attack as simple as SQL injection.

Re: Main GNU source repository server compromised

#3
From the comments on the linked page:

Date: Tue Nov 30 01:34:15 2010 Pseudo: mjflick - Savannah Hacker Comment: re: HappyCrow,

Only one project was targeted in this attack.

Second, a postmortem will be forthcoming, as well as more information shortly from the FSF staff, who are planning on making an official announcement about this.

Re: Main GNU source repository server compromised

#4
post #2

I see a lot of angry comments on their webpage, people asking why somebody would do this. Well, the real answer is probably - simply because he/she could. And to all of those wondering how anybody could do this to a project that hosts free software, well, the attackers don't really care. They saw the exploit and used it. Personally, I expected that a project such as Savannah wouldn't be vulnerable to an attack as sim…

[deleted]

Re: Main GNU source repository server compromised

#5
Ok... I hope I misunderstood this, but does anyone see a problem in the order they're doing this in?

    [X] Reset passwords
    [/] Fix SQL injection and look for potential others
    [ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes
    [ ] Implement password strength enforcement
So they're basically forcing password resets, even though people can use "password123" in plaintext on a site that's not completely audited for vulnerabilities?

Re: Main GNU source repository server compromised

#6
post #5

Ok... I hope I misunderstood this, but does anyone see a problem in the order they're doing this in? [X] Reset passwords [/] Fix SQL injection and look for potential others [ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes [ ] Implement password strength enforcement So they're basically forcing password resets, even though people can use "password123" in plaintext on a site that's…

You eliminated step one, which clearly states:

[X] Put services online using backup, except for password-based ones (e.g. the web interface)

The other step you omitted is the one where they allow people to log in after fixing the vulnerability.

As for the audit, there's no such thing as a complete security audit, and there's no reason to keep the site down in fear of hypothetical holes.

Re: Main GNU source repository server compromised

#7
Headline missed a word : "again"

Original issue date: August 13, 2003

http://www.cert.org/advisories/CA-2003-21.html

ftp://ftp.gnu.org/MISSING-FILES.README

                              Moving Forward
All releases after the 2003-08-01 date will have checksums GPG-signed by the GNU maintainer who prepared the release. This assures automatic certification of the integrity of all GNU source from that date onward.

Re: Main GNU source repository server compromised

#8
post #7

Headline missed a word : "again" Original issue date: August 13, 2003 http://www.cert.org/advisories/CA-2003-21.html ftp://ftp.gnu.org/MISSING-FILES.README Moving Forward All releases after the 2003-08-01 date will have checksums GPG-signed by the GNU maintainer who prepared the release. This assures automatic certification of the integrity of all GNU source from that date onward.

Slightly different, as that compromise was of the FTP servers, which store packaged releases. Savannah is the development system.

Re: Main GNU source repository server compromised

#9
post #5

Ok... I hope I misunderstood this, but does anyone see a problem in the order they're doing this in? [X] Reset passwords [/] Fix SQL injection and look for potential others [ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes [ ] Implement password strength enforcement So they're basically forcing password resets, even though people can use "password123" in plaintext on a site that's…

You eliminated step one, which clearly states: [X] Put services online using backup, except for password-based ones (e.g. the web interface) The other step you omitted is the one where they allow people to log in after fixing the vulnerability. As for the audit, there's no such thing as a complete security audit, and there's no reason to keep the site down in fear of hypothetical holes.

Sorry, my mistake. I got the websiteother services restoration time backwards. Thanks for correcting :)

Re. audit - of course you cannot be sure, but once you get taken over and your system is offline anyways, it might be a good idea to at least grep the sources for queries and quickly check for obvious stuff. Which is what I assume they're doing.

Post reply on HN