GNU Savannah Site Compromised

Trailrunner7 writes "A site belonging to the Savannah GNU free software archive was attacked recently, leading to a compromise of encrypted passwords and enabling the attackers to access restricted project material. The compromise was the result of a SQL injection attack against the savannah.gnu.org site within the last couple of days and the site is still offline now. A notice on the site says that the group has finished the process of restoring all of the data from a clean backup and bringing up access to some resources, but is still in the middle of adjusting its security settings."

Comments

Obligatory...

[Anonymous Coward]

<Nelson>
Haha!
</Nelson>

Re:Obligatory...

[3dr]

Information wants to be free, right?

Encrypted passwords?

[gcnaddict]

They didn't hash the passwords with something decent like SHA2? Really?

I mean if they encrypted them weakly or used SHA1 or MD5, that's about as bad as going plaintext. I'd expect far better from them.

Re:Encrypted passwords?

[macshit]

They didn't hash the passwords with something decent like SHA2? Really?

I mean if they encrypted them weakly or used SHA1 or MD5, that's about as bad as going plaintext. I'd expect far better from them.

According to the announcement, they were apparently brute-forced, so nothing to do with the hash-function used.

Re:Encrypted passwords?

[recoiledsnake]

Add to that that gcc is hosted. Compromise gcc's source and you get access to everything you ever want. Obligatory Ken Thompson compiler trojan article link http://cm.bell-labs.com/who/ken/trust.html#fig6

The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user.

Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions.

FIGURE 7

The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere.
Moral

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect.

Re:Encrypted passwords?

[Anonymous Coward]

While I know and agree SHA1 is broken and MD5 is even worse, SHA2 is still no protection if your password is only [a-z0-9] and a few characters long, or in a dictionary, or findable with a combo dictionary+numbers attack.

Re:Encrypted passwords?

[gcnaddict]

You kidding? That has absolutely everything to do with the hash function used!

SHA1 is highly vulnerable to brute force through optimized attacks. That's why NIST (among others) are recommending moving away from SHA1. Ditto for MD5.

Re:Encrypted passwords?

[recoiledsnake]

A salt + a good hash will prevent against bruteforcing. Encryption will allow the attacker to get the original password back which can be used on other websites etc. Any web site worth it's salt (pun unintended) hashes the passwords instead of encrypting them. Cmon, this is Web Security 101 stuff.

Re:Encrypted passwords?

[Anonymous Coward]

true, though a lot of people use the gcc git mirror AFAIK, so any hole inserted would have to be a sha1 collision too, to avoid alarm bells the first time someone of moderate intelligence pulled (similar to that attempt to covertly insert a hole in linux that was caught). That's not to say it's impossible, just very, very hard.

Re:Encrypted passwords?

[gcnaddict]

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.

Guys, there's a reason for why I'm saying that MD5 is a Very Bad Idea.

Re:Encrypted passwords?

[recoiledsnake]

Umm isn't the git mirror read only and is populated with code from Savannah? In that case you don't need a sha1 collision. Since the attacker had control of the server, he could mask the edits and make a change to the code in the database directly without being logged.

Re:Encrypted passwords?

[falzer]

A different salt for each row in a password file prevents attacking all the hashes at the same time. Offline attacks are still possible with individual salted hashes, no matter the hash.

The threat is reduced, to be sure, but it is not prevented, if I am to take your post literally.

Also, excellent point on encryption.

Re:Encrypted passwords?

[Tacvek]

Add to that that gcc is hosted.

GCC's code respositories are hosted on gcc.gnu.org, a machine also known as sourceware.org, which is owned and operated by Redhat and provides hosting for basically the entire GNU toolchain (automake, autoconf, binutils, GCC, gdb, glibc, and libstdc++)[1].

This attack therefore would not be able to modify the GCC sources.

[1] Notably not present are GNU's bison, libtool, m4 and make.

Re:Encrypted passwords?

[Qzukk]

Salts protect against rainbow tables, not brute forcing. The salt is stored in plaintext with the crypted value (eg $type$salt$hash for the Modular Crypt Format) "Good" hashes are just those where someone hasn't yet figured out a way to calculate that "X#4!./,V3zm" has the same hash that "password" does, and ideally that take a relatively long time to calculate in order to slow down brute force attacks where someone throws a dictionary at the hash and sees if any matches pop out.

Protection against brute forcing is a password that isn't in any dictionary attack database, or a l33t variant thereof.

Re:Encrypted passwords?

[Anonymous Coward]

it's still hashed once it's been imported into git - all changes (unless they collide) should stick out.

Re:Encrypted passwords?

[tsm_sf]

Protection against brute forcing is a password that isn't in any dictionary attack database, or a l33t variant thereof.

So basically most Hotmail accounts have more secure usernames (a la 'HotAunt67') than passwords ('susan').

Re:Encrypted passwords?

[Anonymous Coward]

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.

Guys, there's a reason for why I'm saying that MD5 is a Very Bad Idea.

That's straight MD5. Password hashes, using PHK@FreeBSD's algorithm, is a bit more complicated (e.g., a thousand iterations with a salt):

http://en.wikipedia.org/wiki/Crypt_(Unix)#MD5-based_scheme

Most Linux distributions still use the MD5-based hash for their shadow files. Of course using a new algorithm is probably better, but we're (hopefully) not talking about straight MD5, but rather the crypt/PHK variant.

Re:Encrypted passwords?

[tlhIngan]

You kidding? That has absolutely everything to do with the hash function used!

SHA1 is highly vulnerable to brute force through optimized attacks. That's why NIST (among others) are recommending moving away from SHA1. Ditto for MD5.

That's if you want to intelligently brute force a SHA1 hash. If however the test material is short (e.g., passwords), then it doesn't matter if you use SHA1, SHA2, whatever. Just do a simple dictionary attack first to see if you can get easy passwords.

Re:Encrypted passwords?

[Anonymous Coward]

The collision attacks (*not* preimage attacks) on MD5 are absolutely irrelevant. You have no clue.

Re:Encrypted passwords?

[/dev/trash]

Little Bobby tables!

Re:Encrypted passwords?

[kangsterizer]

It's actually not *that* bad. You can't actually remotely crack MD5 passwords.. or even plain text since you can't access them.

When you can access them it usually means the system is already fully compromised (not in all cases, but in most).
Then, you'd better not be using the same password or key for several systems (Arnold S. says: big mistake.)
Most don't even know, that you can capture plain text passwords from the SSH server when using password authentication, even with nice SHA2 passwords behind SSH. (using SSH keys and disabling password auth is highly recommended).

So having the passwords hashed with a good algorithm is always a plus, but it's not a big step up. It's quite a small one in fact. You see, even salted MD5 passwords are difficult to recover. You'll find dozen of matches and you won't know which one is the actual password if it's not dictionary based. (and even so, you can't use rainbow tables due to the salt, and it will still take a pretty long time).

Using MD5 is however MUCH worse when used as a security checksum: file checksum, certificate checksum etc. Because there's no salting, and there's no need to find the *original* data here.

You just need to make new data that has the same checksum. Much easier if the aglorithm is broken.

This later reason is actually the reason why MD5 (and to some level, SHA1) are truly broken and inadvisable.

Re:Encrypted passwords?

[Anonymous Coward]

Most don't even know, that you can capture plain text passwords from the SSH server when using password authentication

can you back up that claim ?

Re:Encrypted passwords?

[buchanmilne]

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.
 

Why are they limiting themselves to crypt-compatible hashes? Why not just move passwords out of applications/RDMBS to LDAP (OpenLDAP already has sha-2) or Kerberos? And if they are considering crypt-md5 an improvement, what *were* they using?

Re:Encrypted passwords?

[Linuxmonger]

A salt + a good hash will prevent against bruteforcing.

No, it won't. A whitelist of ip addresses helps, adjusting the timing of acceptance helps, but eventually, brute force works.

Re:Encrypted passwords?

[ArsenneLupin]

Most don't even know, that you can capture plain text passwords from the SSH server when using password authentication

can you back up that claim ?

I think he meant in the case where the server is already compromised...

Re:Encrypted passwords?

[Anonymous Coward]

Various Unixes, including Linux distributions like RHEL / CentOS include a modern algorithm inspired by PHK that uses the later SHA family algorithms, and has variable rounds.

But keep in mind that despite all the tutting from know-nothings on Slashdot who react to keywords like 'MD5' even the original DES-based Crypt remains remarkably secure. While a Windows password or MD5 rainbow table is something you can get from any Torrent site, crypt tables still don't exist. While Windows brute forcers can chew through eight alphanumerics while you wait for your pizza to cook, crypt will take weeks.

Basically, other systems spent the early 21st century catching up to where Unix was in the 1970s.

And none of this helps you when a user picks something dumb like 'linux' or 'opensesame' as a password.

Re:Encrypted passwords?

[ArsenneLupin]

You'll find dozen of matches and you won't know which one is the actual password if it's not dictionary based.

Just pick any match with characters enterable on the keyboard.

Using MD5 is however MUCH worse when used as a security checksum: file checksum, certificate checksum etc. Because there's no salting, and there's no need to find the *original* data here.

Neither is there for passwords. As long as the MD5 matches, and is enterable on the keyboard, it would work on that system. Think about it...

So, it's really only a matter of protecting other, unrelated systems, on the off chance that the user uses the same password elsewhere (there, only the real password picked by the user would work, as they would probably have a different algorithm and/or a different salt).

Re:Encrypted passwords?

[kailoran]

Obligatory David A. Wheeler's "Fully Countering Trusting Trust" piece link: http://www.dwheeler.com/trusting-trust/

Re:Encrypted passwords?

[kangsterizer]

You'll find dozen of matches and you won't know which one is the actual password if it's not dictionary based.

Just pick any match with characters enterable on the keyboard.

Which doesn't help finding the real password, if you have access to the hashes, you have most likely already compromised that system. So the point of being able to login is kinda moot. I did specify that.

Getting a file to match a checksum or a certificate to match a checksum is much more dangerous.
You can upload a trojan and make it appear legitimate. You can forge a fake SSL certificate and make it appear legitimate.

Re:Encrypted passwords?

[ArsenneLupin]

There are situations where the hashes may be accessible without full compromise of the target system:

• Old Unix systems had hashes in /etc/passwd, which must be publicly accessible (nowadays, they use /etc/shadow, but this has not always been the case)
• NIS makes hashes available for NIS clients, meaning that in sufficiently old versions, anybody on the local net can get them
• Many routers include hashes in their config dumps (which may be accessible by users without full privilege)
• Depending on how Apache is configured, the hashes for password protected web pages must be world readable

For these situations, having a strong hash, and a difficultly guessable password is important.

Re:Encrypted passwords?

[kangsterizer]

They did specify they want to use shadow with MD5 here tho (and those are certainly salted). Not that it's all that advisable, it's just not as horrible as some maybe think.

Nice bullets M. Lupin ! :)

Re:Encrypted passwords?

[rgviza]

Actually this depends on what context "brute force" is used in.

In the traditional definition of a brute force attack:
Hashing is used to store the password so you can't read it simply by looking at the table data. When entering your password to log in, it's hashed then compared against the hash in the database.

How easy a password is to brute force depends 100% on how good the password is. Like he said, it doesn't matter what algorithm is used to hash the passwords for purposes of a brute force attack you are guessing the password, not decrypting the hash.

A brute force attack to break the salt, yes, that does depend on the algorithm.

This is an attack that would lead to better results since you could decrypt every password in the database once it was completed, and this would lead to compromises on other systems once a users email and password are known, since most users use the same password everywhere. Brute force password attacks only operate against one account password at a time so could be a lot slower to get the same result.

Currently SHA-2 is top dog as far as I know for unclassified hashing algorithms. There are SHA-3 finalists. Once they are selected SHA-3 will replace 2.

You can also use block cipher algorithms such as AES-256 or RSA-2048, but they can actually be less secure when used as hash functions than SHA-2, since they are intended to encrypt and decrypt data, not create cryptographically strong hashes.

This is why md5 is bad. There's commonly available code to reverse md5's function. You can simply crack the salt in a few minutes.

First...

[Anonymous Coward]

If Slashdot's database does not get damaged in any way, that is

"restricted"? author of exploitable code?

[MichaelKristopeit162]

if it's on the same database utilized by a public facing web server, who exactly thought they were "restricting" anything?

who is responsible for the software that enabled the SQL injection?

So?

[razvan784]

"enabling the attackers to access restricted project material." So? I though it was all about free & open source. Therefore, what restricted material?

Re:So?

[MichaelSmith]

An attacker could insert an exploit into GNU software, which would be executed downstream by users who expect Savannah software to be safe to use.

Re:So?

[Anonymous Coward]

You're of course right, open source obviously means that any 13-year old Russian kid can modify the source of well known core software to every Linux distribution without ever needing approval or anyone knowing what changes he made.

Re:So?

[vlm]

"enabling the attackers to access restricted project material."

So? I though it was all about free & open source. Therefore, what restricted material?

Personal contact info for copyright assignees beyond the legally required minimum?

Private GPG keys?

Just making some good guesses.

Re:So?

[Anonymous Coward]

Everyone has things that need to be confidential. Just ignore this Microsoft Trollie.

Re:So?

[Magic5Ball]

Why not just retcon it as a WikiLeaks release and turn this event into a PR opportunity?

Obilgatory

[hairyfeet]

You'd think a site like GNU would have better coders that wouldn't fall for a Bobby Drop Tables gag. I thought the GNU was full of wise old neckbeards?

Re:Obilgatory

[Anonymous Coward]

Does it look to you like this GNU code was written by a wise old neckbeard? It's 780 lines of unreadable crap. This is what the code of a wise old neckbeard looks like.

Re:Obilgatory

[Anonymous Coward]

Most of that GNU code is perfectly readable. The only thing that I found even slightly annoying was the formatting. Furthermore, the Plan 9 code doesn't provide the same functionality (documentation, command line options etc.), doesn't handle any special cases, and is slower.

Re:Obilgatory

[greed]

Your AT&T example will fail on systems with interruptible system calls: it has no mechanism for distinguishing EINTR from any other failure mode.

On Plan 9, that may be a valid assumption. Under SuS, SVR4, and POSIX, it's not.

Re:Obilgatory

[Anonymous Coward]

The program doesn't directly make any syscalls, but uses libc wrappers around them. How do you know that EINTR isn't taken care of inside read() and write()? I know from personal experience that this code (and the code of many more substantial programs) runs perfectly well on Linux and FreeBSD without modification, and it reportedly runs on many more platforms than that.

Re:Obilgatory

[Anonymous Coward]

• Documentation
  The man page explains the program.
• Command line options
  Cat shouldn't have any. Its purpose is to glue inputs together. Everything else that GNU cat does can be done better with awk.
• Special cases
  Name some.
• Slower
  Did you determine that with a benchmark? I have a feeling you didn't, because my tests show that they have equal performance.

But Linux is TEH SAFEZORZ!

[DriedClexler]

I thought Linux was always 100% secure, completely unhackable, because they're the admins are experts and the software has built in security! You mean ... it's not true?

Re:But Linux is TEH SAFEZORZ!

[Anonymous Coward]

Not if you are root.

Re:But Linux is TEH SAFEZORZ!

[MichaelSmith]

I thought Linux was always 100% secure, completely unhackable, because they're the admins are experts and the software has built in security! You mean ... it's not true?

Maybe this one runs HURD.

Re:But Linux is TEH SAFEZORZ!

[LWATCDR]

It was a GNU project it was running on HURD not Linux.

Umm.. this wasn't a LINUX issue it was an SQL injection attack on a website. Are just trying to troll or do you really not know the difference?

Re:But Linux is TEH SAFEZORZ!

[maxwell demon]

They didn't hack Linux. They hacked the web application running on it. Even the best operating system cannot protect you from that.
You don't complain about the car's safety if you manage to cut yourself with a knife while inside, do you?

Re:But Linux is TEH SAFEZORZ!

[recoiledsnake]

It was a GNU project it was running on HURD not Linux.

Umm.. this wasn't a LINUX issue it was an SQL injection attack on a website. Are just trying to troll or do you really not know the difference?

This is definitely a LINUX issue because GNU utilities(like gcc) are bundled with almost every Linux distro. If someone were able to slip a trojan into gcc or any other GNU util, it's game over for every Linux installation. http://cm.bell-labs.com/who/ken/trust.html#fig6

You're the one who's shortsighted to think that it's isolated to HURD.

Re:But Linux is TEH SAFEZORZ!

[recoiledsnake]

How do you know a trojan wasn't slipped into the various software source hosted by the Savannah server like GCC, the GNU utilities etc.?

You don't complain about the car's safety if you manage to cut yourself with a knife while inside, do you?

No, but you would complain if the people responsible for ensuring the safety of the car run red lights themselves and put others at risk. That's what happened here. The hardcore admins themselves didn't follow basic security procedures like hashing passwords and protecting against injection attacks.

Re:But Linux is TEH SAFEZORZ!

[revlayle]

or DERP

Re:But Linux is TEH SAFEZORZ!

[MichaelKristopeit162]

your tattoo says "dude"... your tattoo says "sweet".

the vulnerability to isolated to an SQL injection attack. the consequences of exploitation are certainly a LINUX issue, among many other things.

Re:But Linux is TEH SAFEZORZ!

[MichaelKristopeit178]

why did the car allow you to bring a knife inside?

Re:But Linux is TEH SAFEZORZ!

[gringer]

You're the one who's shortsighted to think that it's isolated to HURD.

I think GP was pointing out [at least] two things:

1. A GNU operating system is possible without the Linux kernel (i.e. GNU/HURD rather than GNU/Linux)
2. An SQL Injection attack doesn't care much about the underlying operating system

They don't appear to think it's isolated to HURD. I interpreted the statement "this wasn't a LINUX issue" as meaning Linux isn't a necessary precondition for attacks of this nature.

Re:But Linux is TEH SAFEZORZ!

[LWATCDR]

Was it running HURD? I was actually kidding about that.
An SQL injection attack is so many levels removed from the OS that it isn't funny. Frankly it is OS independent in the extreme.

Re:But Linux is TEH SAFEZORZ!

[sumdumass]

I know you are just trolling, but even cursory glance at the article summery would tell you that this wasn't a linux problem, it was an exploit to a service running on the linux. Linux doesn't Nativity process SQL code until some SQL server service is installed and running. I know it's difficult to understand that an SQL server is different from an operating system when your a windows point and click jockey but you can look it up if you need to learn more about it.

Re:But Linux is TEH SAFEZORZ!

[sumdumass]

How do you know a trojan wasn't slipped into the various software source hosted by the Savannah server like GCC, the GNU utilities etc.?

Didn't you read the part in the article summery where they said that have restored everything from known good backups?

How you know is by a hash file. You hash the files, store copies of the hash on systems other then the one the file it on, then you compare the hash of the current file with the known good file. If they match, they are good. If they don't, they aren't good.

No, but you would complain if the people responsible for ensuring the safety of the car run red lights themselves and put others at risk. That's what happened here. The hardcore admins themselves didn't follow basic security procedures like hashing passwords and protecting against injection attacks.

True, but not all is lost as you seem to make it out to be.

Re:But Linux is TEH SAFEZORZ!

[Anonymous Coward]

You sure love that cock don't you/

Re:But Linux is TEH SAFEZORZ!

[sfraggle]

Are you seriously trying to claim that GNU run their production servers on Hurd?

Come on, they do some crazy stuff but they're not THAT crazy.

Re:But Linux is TEH SAFEZORZ!

[LWATCDR]

ahhh.. No but no one else seemed to get it... The rest of the comment was serious but yea I fear I aimed too high with the Hurd joke.
But you know from the description of the error I think that GNU really does to start running Hurd on the Savannah project...

Nothing new

[recoiledsnake]

Red Hat/Fedora servers had been hacked compromising the private signing key http://www.pcworld.com/businesscenter/article/150212/hackers_crack_into_red_hat.html

Ubuntu repositories hacked http://www.pcworld.com/businesscenter/article/150212/hackers_crack_into_red_hat.html

And don't forget the Debian SSL key debacle....

Re:Nothing new

[atomic-penguin]

This is pointless moderator abuse. Simply pointing out other significant compromises related to Open Source does not make one a troll. Even if he did post the same link twice.

The Debian OpenSSL debacle was probably the most far-reaching compromise affecting developer signing keys, commercial certificate authorities, server certificates and keys, user ssh keys.

Sequel

[Anonymous Coward]

a SQL injection

Well, we know how the author pronounces SQL now; I have always preferred "an SQL injection"---that is, "S.Q.L."

Re:Sequel

[Anonymous Coward]

Nobody cares.

Re:Sequel

[butalearner]

a SQL injection

Well, we know how the author pronounces SQL now; I have always preferred "an SQL injection"---that is, "S.Q.L."

What, you don't mentally pronounce all acronyms? Well, now, aren't you just a SOB.

Re:Sequel

[Anonymous Coward]

You cared enough to reply.

Re:Sequel

[Anonymous Coward]

SQL is pronounced SQUEAL.

Re:Sequel

[Anonymous Coward]

It can be debated whether SQL is an acrynom or not.

Re:Sequel

[L4t3r4lu5]

No it can't. SQL is not an acronym, it's an initialism. It's pronounced as separate letters. PostgreSQL is pronounced Postgres Queue Ell. Calling SQL "Sequel" is incorrect.

Re:Sequel

[Anonymous Coward]

Yes but is it "an SQL injection" or "a SQL injection"? I always find myself writing the former and revising to that latter during proof reading. Where are the grammar nazis when you need them?

Re:Sequel

[L4t3r4lu5]

It's "a SQL injection". It is a soft "a" sound, like in "rain" or "change".

Re:Sequel

[Anonymous Coward]

"Ay Ess Queue Ell injection" or "An Ess Queue Ell injection". Unless you're pronouncing SQL as a word (such as squeal [yes, someone tried to convince me that was the original intent] or sequel) then it's "A [sequel/squeal] injection".

The reason for the 'an' is to make the spoken text flow from your mouth easier. "A apple" could be pronounced "uh apple" requiring a break in the breath between the vowels, or "ay apple" which requires one to slow their speech to form both the "ay" and the "app", where "an apple" requires neither instead letting the tongue make the break and keep air flowing (notice that 'n' is nasal).

Let's see...

[filesiteguy]

DROP ALL

nope.

UPDATE USERS SET PASSWORD = '1234' WHERE NAME = %

nope

Dang, this Leenux stuff is way more secure than I thought!

Re:Let's see...

[filesiteguy]

I got modded offtopic?

Sheesh! You make a joke about sql injection in a thread about a site getting compromised by a sql injection and it is offtopic? /shakes head...

Re:Let's see...

[TheLink]

Clearly your joke injection failed.

Re:Let's see...

[Anonymous Coward]

You know when you say something and people laugh? Hint, they are laughing at you, not with you. Around here, "laughing at" usually translates to a offtopic mod. Hope this helps in your future posting career.

Suggestion

[Anonymous Coward]

They should use Windows 7. They could avoid this kind of attack.

Re:Suggestion

[recoiledsnake]

You mean Windows Server 2008 R2?

Re:Suggestion

[WrongSizeGlass]

They should use Windows 7. They could avoid this kind of attack.

Not when Diasposa's security code is available ;-)

Re:Suggestion

[Anonymous Coward]

Diasposa's

You may want to re-check your spelling of that. Admittedly, the /. URL was wrong as well (but the title was changed to the correct spelling).

Re:"restricted"? author of exploitable code?

[larry bagina]

savannah is a branch of sourceforge. Sourceforge was originally open source, but VA Linux/VA Research/OSDN/Sourceforge.net/Geeknet or whatever they call themselves these days closed it up.

Exposed!

[Anonymous Coward]

Can't wait to see the files on Wikileaks! Go Julian!

gnu site hacked

[Anonymous Coward]

hackers gained complete access, and nothing of value was found.

I kid.. I kid

Not the first time.

[molo]

GNU Savannah was hacked in 2003 also. http://news.cnet.com/2100-7344-5117271.html

"We expect to take measures in the aftermath of the Savannah incident," said Eben Moglen, general counsel for the Free Software Foundation, which maintains the GNU Project, a source of freely available software for Unix and Linux systems. Among the measures, the project leaders will force developers to digitally sign any code they submit, and they plan to introduce additional features to freely available source-code maintenance systems--the best known being the Concurrent Versions System, or CVS--to check developers' digital signatures before accepting changes.

"We believe (adding digital signatures) is the single most useful technical change to tighten these systems to assure the integrity of the code they contain," Moglen said.

Does anyone know if the changes described here came to be? Did they help at all in this attack?

-molo

Re:Not the first time.

[jrumney]

They changed CVS and other version control systems hosted on savannah to require ssh key based logon for write access. It's not quite what is quoted, but a big step in that direction that was immediately achievable without waiting for the changes in CVS and other programs. They did change the FTP upload process to require GPG signatures for all uploads.

However the web based system that was hacked this time around has a password based login, and allows users to change their authorized SSH keys. It also allows users to register a GPG key, but this is just to allow project members to share their keys (and probably intended for future use when signed commits is available and working), the FTP keyring is more tightly controlled.

Brace yourself for the wikileaks post!

[synthesizerpatel]

This can only be the precursor to the wikileaks post where they blow the lid off the GNU world by releasing a torrent of source code! Run for the hills!

Re:Brace yourself for the wikileaks post!

[sumdumass]

Nah, wikileaks only seems interested in harming the US government and the US economy.. That would seem to be beneath them as it could potentially help.

Re:Brace yourself for the wikileaks post!

[Doctor_Jest]

That's actually very funny, but I suspect that you'll be modded as troll or flamebait before it's all over. :-/ Shame too, because it's the kind of humor we need around here. :)

SQL Injection attack

[mevets]

If you have a sign on your back that says "kick me", and people kick you, it isn't an attack. It is a response to an invitation.

A net-facing program which just blindly passes whatever crap is input into another programming language (sql, in this case) is simply stupid, broken, and wearing a "kick me" sign.

If my net facing program just bundled user input into 'cmd', and did "system(cmd)"; you would hardly consider that a "shell injection attack". It is simply really bad software. No need for fancy terms.

I thought GNU was about being open

[slapout]

"GNU free software archive" and "access restricted project material"

huh?

Note that...

[Anonymous Coward]

As has been the case for quite some time, the US makes the biggest screw ups, so it's not exactly an anti-US thing but merely a symptom of the US having to have the biggest/best of everything. In this case it's "Hell son, if you're going to have leaks, make them of a Biblical kind/quantity! That's the American way!"

Theft

[Anonymous Coward]

Did the attackers manage to steal any code?

Old news

[Anonymous Coward]

I posted the exact same stuff yesterday, but my story was not accepted.

Obviously my name is not CmdrTaco....

The code is now contaminated

[Anonymous Coward]

Damn, there have been malicious commits already. Look what I got compiling the latest GNU Bash!
http://img88.imageshack.us/img88/984/clippyinconsole.jpg

Hacker was 15 years old

[EMOziko]

Hacker was 15 years old. Yes it's true. You can see his blog post about this fact http://vaska94.net/2010/11/27/gnu-defaced/

Reconstruction of the incident

[_bernie]

Free Software Foundation website published a detailed chronology of the incident.