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

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?

[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?

[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?

[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:Sequel

[Anonymous Coward]

Nobody cares.

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.