Intrusion Cleanup Forces Delay For GNOME 2.6

An anonymous reader writes "Looks like the GNOME site (both web and FTP) is back up and running again (from a replacement system). The restoration work is still going on, and dynamic content does not work yet. Bugzilla should be up by tomorrow (it is already in testing mode). More details are available in this announcement. Kudos to the GNOME sysadmin team for such a rapid recovery." However, blurzero writes "GNOME 2.6 was scheduled to be released sometime today, however after evidence of possible intrusion on the web server, the release has been delayed by one week, until March 31st." Update: 03/24 14:08 GMT by T : An anonymous reader points to this story on the delay at ZD Net Australia.

Comments

Must've been a real bugger

[James A. M. Joyce]

Intrustion cleanup is a real bastard to carry out with any degree of success. There's really no way to prove that there isn't just one more subtle little backdoor hiding in the system, in your repository or in your /home area. This is a case where an ounce of prevention is better than a pound of cure. It's too late, here, unfortunately, so they should probably have rolled back to a backup on another set of boxes. (Just my two cents.) How well would TripWire have worked in this kind of situation? Or is that ineffective against an all-out rooting?

Re:Must've been a real bugger

[Anonymous Coward]

They have TireWire and it didn't work.
TripeWire never works.
I've seen TW failing and being exploited in several installations.
Since the release of wirecutter TripWire has become fucking useless.

Re:Must've been a real bugger

[Penguinisto]

It takes some work, but there is one way to insure a completely clean system: Re-installation of the OS from media, or a backup from a time known before the break-in.

Either way, you only have to check the backup server data itself against (externally backed-up) MD5 checksums, and ask developers to re-commit any changes made during the suspect time.

Now try and do that to a mail server, and the fecal matter hits the air-handler. But, with data that is relatively static by comparison, it takes work, but isn't too much of a trial.

$0.98 in change, please :)

Dammit...

[thames]

now I have to go to two geek parties in one week

Boy, that was a close call

[El Cubano]

"GNOME 2.6 was scheduled to be released sometime today, however after evidence of possible intrusion on the web server, the release has been delayed by one week, until March 31st."

That could have been disasterous had they been forced to delay until April 1. Imagine all the jokes that would have ensued.

Awwww man!

[chendo]

Now we have to wait one WHOLE week?

Maybe the KDE team did this to slow Gnome down... :)

By the way, I've tried CVS metacity with FD.O's Xserver..... funky stuff. Translucency when you move windows! Although it chews a fair bit of CPU (when moving the window itself, that is, as just holding the window still doesn't chew CPU), it should be fixed when we finally get HW acceleration. I was able to get MPlayer to play a video in the background, hover a window over it and watch it through it. ub3r cool stuff.

Well, there is one difference I appreciate...

[Penguinisto]

With GNOME and most other F/OSS projects, at least you get honest, up-front answers and timely announcements of intrusion attempts and such.

If only MSFT (and more importantly, proprietary software companies that aren't so much in the spotlight) were as forthcoming about break-ins.

Re:Well, there is one difference I appreciate...

[Penguinisto]

" What does Microsoft have to do with this? You fucking dumb jackass."

Well kiddo, it's not just MSFT truth be known (hence my mention of "more importantly, other proprietary companies..." )

Most proprietary companies are too worried about "customer confidence" to actually be honest with their customers. Back when a group of russians had 3 months' unlimited access to Windows' source code, it took outright proof in public before MSFT would admit to such a thing. ...and that's just MSFT; I wonder how many times Adobe's servers have been compromised? It would be nice to know that P-shop and Acrobat (or worse, the free reader?) wasn't quietly trojaned-up and sleeping on my 'dows boxen.

Now, what about the break-ins we don't know about? How were they handled? How can a proprietary software company, let alone its customers, be sure that there aren't any nasty suprises hidden in their products?

...and therein lies the crux of my argument - open-source companies are specific, honest, and, well, eopn about what goes on security-wise.

It's damned refreshing to be a customer who is treated like an adult, and not lied to, or kept in the dark about the products I use.

Does this answer your question?

I suppose

[AnonymousCowheart]

I suppose this will get modded as a flame bit, but a lot of people were cheering when Bill Gate's credit card number got stolen just wondering how those people felt now? I know there was no "real" damage in that case, and in this case the server was offline, but still something to consider. Maybe these people were also "trying to help" by showing a server insecurity.

Dumb Cracker?

[gscott]

According to Waugh, the GNOME Web servers that are hosted by Red Hat were compromised by "a dumb cracker who probably didn't realise what they got into".

Seems like he was smart enough to hack their system.

Re:Dumb Cracker?

[stevey]

It would be interesting to learn how the compromise had occurred.

I'm guessing that all the important services would have been up to date (ssh/rsync/apache/etc) - so that leaves a password/ssh keycompromise, or some scripting flaw..

I hope we find out once the cleanup has been completed.

Re:Dumb Cracker?

[Fluffy the Cat]

The machine in question isn't run by Red Hat admins.

Re:Dumb Cracker?

[Too Much Noise]

Not really. Here's a scenario for you (the debian-style):

• cracker compromises a 3rd-party machine and gets the ssh tokens for a legitimate user.
  
• cracker logs into the server - no particular preference, that server just happened to be one of those he gained access to by sniffing on ssh logins from his initial machine
  
• cracker logs in as a legitimate user on the server (impossible to detect at this stage) and acquires, in some way or another, root access (like a nice, untraceable pam exploit)
  
• cracker tries to secure root acces and triggers an allert in the logs (this being the 'dumb' step)
  

the problem is, you can't trace the initial attack vector. It can be done by any script kiddie who compromises a machine that some developper uses. However, if it's not a mere script kiddie (and covers his tracks successfully), chances are that even a competent sysadmiin can fail to discover it. Yeah, I know about read-only/remote IDS databases, remote logs, backups and so on. It's a nice overhead when you're handling a large farm and you still have to make sure the data is on a secure machine. Do you do it for all your servers? (besides, at this level of complexity you need a full-time job - at least experienced hackers will see it coming and maybe leave you alone).

that said, whoever was the sysadmin for that box picked it up - kudos for that! And if the 'dumb cracker' line means what it says (from the logs, etc) then here's hoping that it was indeed just a lone incident.

Intrusion Method Same Of Gnu.org Intrusion?

[Goo.cc]

From what I have read, intrusion details have not been released yet but I wonder if the Gnome server was compromised the same way the gnu.org server was last year. If so, that would be disappointing.

Still, I am happy to see that this will not push the next version of Gnome back very much. It is really starting to look nice to me and I am a Mac OS X user.

Deja Vu

[Anonymous Coward]

This event immediately brought thoughts of Half-Life 2 to mind.

I bet in a week the source code for GNOME 2.6 will be all over the Internet, free for anyone to take, read, and use!

Re:Confidence ?

[prisoner-of-enigma]

How do you know the MD5 wasn't made after the intruder got in? It wouldn't be very valuable then, would it?

The point is, after a breakin you must determine when the breakin occured, because everything after that is suspect. The problem is it can sometimes be very difficult -- or impossible -- to determine when the breakin happened. Then you're really, really screwed.