SourceForge Server Compromised 199
justrob writes: "Looks like there was a massive security breach at Source Forge.
I wonder if this what caused the 'unscheduled maintenance event'
that has left the shell servers unavailable for a week. Here is part of an email I recieved:" (Read more below.)
"Dear SourceForge User,The SourceForge team takes security very seriously. This week, one of our systems was compromised. We have promptly taken the necessary steps to correct this situation.
You have been contacted, because according to our log files, you have used SourceForge during the past week and may have used the system that was compromised. In order to complete the security fix, we are asking all users who used the system to change their password immediately. We've reset your password to a randomly generated string. "
Here's where to go if you think your account might have been compromised.
Centralization and the Internet (Score:1)
Re:Care to back that up with facts? (Score:1)
Is that the sound of a three headed dog barking? (Score:1)
Re:yes, well (Score:1)
Re:Errr (Score:1)
Re:You must be joking (Score:1)
Oh Joy. (Score:2)
1 Basket.
Lovely news, but hardly a surprise.
Re:yes, well (Score:2)
Thats why I'm writing an os with stupid admin built in.
How dose it work?
Well you set it up and tell it what you are doing. It installs all the software etc and sets everything up at the WORST possable setting.
The os has a built in test to see if any built in back door remains.
The SysAdmins job is to find all the back doors (with that tool locked out) and close them.
The manager then unlocks the tool and checks the SysAdmins work.
In otherwords... It's an employment test...
Closed source of course...
Re:They should provide more details (Score:3)
A developer with any sense is going to do a cvs diff and verify any changes before continuing on like usual. No big deal really.
Re:Bad Bad Bad, webmaster. (Score:1)
--
How Secure? (Score:3)
Perhaps the authors of the programs should check out their software to a different directory and do a diff.
I am happy to say I don't rely on sourceforge. It is a mistake for a large part of the community to rely on one site for this sort of thing. I run my own CVS server, and am about to pay a small amount ($10/m) for an ISP to host my hobbyist code. Granted, it doesn't have all the features of sourceforge, but I don't mind.
Re:concerns about valinux (Score:1)
Re:Repercussions and Security Theory (Score:2)
And you've still got the problems I outlined before. And how are the login servers interchangeable? They can't all store all the pieces of the passwords, because that defeats your scheme entirely by storing the entire password, unencrypted, on every server.
I'm sorry, I just don't think this will fly. :]
Re:Repercussions and Security Theory (Score:4)
Full usernames do need to be known, because you're dealing with a multiuser system where users like to interact with each other. What happens if you run 'w' on a system like the one you're describing? Using uids for most things would work, but remember that humans use this stuff, and people like to have names, not numbers. If I do an 'ls -l', I don't want to see that a file is owned by user 11203, especially if for the sake of security I don't get to look up who the hell user 11203 is.
Your system could work if applied to the passwords, but it would gain you nothing. Any sane system already uses a hidden password scheme, most commonly shadow. The system never stores the actual password anyway. What it stores is a hash (MD5 usually, these days) that it can verify another (dynamically generated) hash against. Your system does not remove this dependancy on having the hash accessible on each authentication server. You have to have the sum there to verify against. How else would your systems verify that there is a string with "those two letters in that particular position... associated with that particular cryptographic sum"? In fact, your system would have to store the two letters in question and their position to do so.
Bam. You've created a less secure system than the currently existing one, because you've just fed a brute-force password cracker two of the characters it needed for each password, if that file is compromised.
Sourceforge, single point of failure?! (Score:3)
-adnans
They all don't offer CVS access... (Score:2)
Re:Repercussions and Security Theory (Score:2)
Re:Repercussions and Security Theory (Score:2)
Now, obviously, the details are fuzzy, but hey, that's life.
Repercussions and Security Theory (Score:5)
And even if they did know, would that help, I wonder? Is user information distributed within the SourceForge network, or is there a more central login server that warehouses all of that information? Either case, when you think about it, is somehow not exactly what you want to have happen. If all user login information is in a central location, cracking that one location would instantly compromise everyone's account information. However, distributing user information around the network (aside from making login management more difficult) makes it more likely that if a random server is cracked at least *somebody*'s account information will be compromised.
It occurs to me that a distributed, and cryptographically fragmented form is the most desireable - because then cracking any one machine would give you exactly nothing in the way of user account information.
Now, the rest of the problem is people who use the server that has been compromised. They send their usernames and passwords to this compromised server (unawares, of course) and thus their information is compromised, obviously. But does it have to be this way?
I propose that it is conceivable to build a login system where no one server receives an entire piece of a login. The login name is split into two character pieces, for example, and sent to as many servers as necessary along with an MD5/SHA1 sum of the full username - each server verifying that there exists a login name with those two letters in that particular position, and they are associated with that particular cryptographic sum, and nothing more. Notice that the controlling server (the one that you're logging in to) never sees any piece of the login name - but is merely informed (by the client) which machines (in no particular order) the login name pieces were sent to. A similar trick could then be played with the password - sending pieces of the password to some password verification servers, with a cryptographic sum of the verified login name. So, each server never has a record of full login names, and no server ever is sent the full login name.
To bad no such system exists, eh?
Re:The OS on sourceforge.net (Score:3)
Re:The problem with source diffs (Score:2)
A developer can type "cvs diff -r HEAD" to see what has changed between whatever is checked in and what they have on their local store.
Actually the idea that the hackers would do this is rather silly. This was also suggested that hackers into MicroSoft may have modified the Windows source code to introduce back doors. Anybody who thinks this is possible should be writing movie scripts.
Huh? (Score:2)
Of course passwords could be compromised, which means the silly monkeys that use "er33t" as the password for sourceforge, slashdot, freshmeat, and hotgoatsex.com will have to change the passwords in different places too.
What are the implications of this security break in? I'm open to the idea that they're larger than just vandalism of source code and passwords, but what's the bigger problem?
Re:Repercussions and Security Theory (Score:3)
The system that you describe sounds really nice, but it still doesn't deal with the intruder that replaces your authentication mechanism with one of their own. Your method of distributing parts of the account information to mulitple machines would prevent someone that is listening near one of the authenticators from getting all of the info. Why would they go to all of that trouble when they could compromise one machine on the network. After you compromise the machine, all you need to do is write a program that will pass i/o between the user and the other parts of the system.
This is why they say that "security is a process." You could have the coolest, geewhiz, unbreakable cryptosystem in the world. But, if someone put a sniffer between your keyboard and computer, what good is it?
My guess is that this is what happened here. Someone compromised the system and had the ability to change the authentication systems.
I would've thought that something like Tripwire would have been used to check for possible changes in the system. Nothing is infalliable though and that is the most important thing to keep in mind.
Besides, for a site that hosts ~21,000 projects and has ~180,000 users, I think that it's pretty amazing that it hasn't happened sooner
Re:Huh? (Score:1)
Of course if you have access to both, then its trivial to replace the key with a new version which would accept the trojan.
Re:Huh? (Score:1)
If however a user just grabbed the latest version before the developer has resigned and repackaged it, along with the original (valid, unaltered) key, then the signing checking should point out the difference. Of course, if you had the key on the same server as the tarballs/rpms then it is of course totally irrelevant as the key could have been altered too.
Ewan
Re:Huh? (Score:5)
Then, when you download and install something, you would also install a back door for the cracker to use to easily gain access to dozens, hundreds, or even thousands of machines.
Of course, GPG signed tarballs are what you would normally use to verify the files and protect against this, but how many people actually bother with that?
Ewan
Re:Windows 2000 secure? Yah, right... (Score:1)
I think inferring relative OS security based on web site defacement would be a mistake.
-Kevin
Re:Windows 2000 secure? Yah, right... (Score:1)
As far as your question about choosing between two platforms: I don't think an IT organization would make a decision based on security alone, it would be a decision driven more by cost of ownership and other logistical (e.g. in house expertise) / economic factors.
-Kevin
Re:SSH key info on SF (Score:4)
Access to the authorized keys means that the intruder(s) could have added their own public keys, thus ensuring future access. The problem is not public key hashes being stolen.
-Kevin
Re:Errr (Score:1)
Aye, two Wrights make an airplane.
Re:open source myth (Score:1)
However, they were fired for relying on it.
eggs. baskets. (Score:1)
We need a good, polite, robust, idiot-proof "mirror" script so that the folks who are interested in this stuff will be the backup of last resort more reliably.
Re:yes, well (Score:1)
That was excellent.
Re:yes, well (Score:1)
While in my embryonic linux stage, I had two boxes cracked, and it was due to the default services (at their default configs) left on by the RH install, and then by me as I didn't know to turn them off (or how to check that they were on, how to know what the given services were for, etc.).
Of course, getting cracked was an *amazingly* effective incentive to learn how to secure a system, which is why I haven't had a box cracked since those initial two. It also planted the seed of my now-healthy sense of paranoia, which contributes greatly to my skills in system administration.
Anyways, RH's installation left a lot to be desired. It *still* leaves something to be desired, but they are improving. I'll stop there, as this subject has been discussed into the ground many times.
human error != stupidity (Score:2)
First, just because someone makes an error doesn't mean they made a stupid mistake. Just as we don't know whether this was human error or buggy software, we don't know if this was a stupid mistake or an easily made error.
Second, robustness (i.e. lack of error proneness) is indeed a feature of all software. Human error rate when performing a task is a useful metric for evaluating software usability. An OS that is "easy to secure" has a feature that many would find advantagous.
Ideally, computers should serve humans. Making a task error prone requiring a human to go through the proper hoops or suffer a security breach is a reversal of this ideal.
Re:How Secure? (Score:2)
For this very reason the FSF [fsf.org] started their own server [gnu.org] using the SourceForge software. The FSF plans to use it to manage their projects but, like SourceForge, it is open to the public. All the amenities of SourceForge without having a single point of failure.
Re:Huh? (Score:2)
I have no more information than you do but I kind of doubt that anyone was running around their network, undetected, for that kind of time. That really doesn't change the meat of the argument, though, restore the data (only) from the last known-good backup and rebuild everything from then to now by hand.
Re:Huh? (Score:5)
Sure code could be modified, but not without being detected. I assume that they are going to restore the data from a pre-breakin backup, then diff the backup with the current data and ask the various software maintainers to verify the diffs. Alternately they could require the various software maintainers to checkin their local CVS tree with the master repository, and verify any discrepancies. Any time you have a properly implemented change control system like CVS it is scads easier to recover from a comprimise like this and ensure that your source code has not been comprimised. This isn't scary at all.
SourceForge was warned months ago ! (Score:1)
Re:Huh? (Score:1)
And how would this help? If a backdoor has been inserted into the CVS version of a project, then the maintainer of the project would inadvertantly include the backdoor (assuming s/he didn't notice it already) in the tarball. S/he would then sign it, and you would assume it to be safe.
GPG-signatures can (at best) only prove that the package you downloaded is the same one that some known user uploaded -- they can't prove that there are no backdoors in the code, planted by either the gpg-signer or a third-party before the code was signed.
s/gpg/pgp/ if you like; they're the same.
// mlc, user 16290
--
Re:Lets slow down a little, shale we? (Score:1)
It could have been the sock people...
It could have been CmdrTaco over his contention that it's Gnu/Linux...
I'm kidding.. but you have a point...
IMHO It really dosen't matter what you use. Hire a good admin let that admin run what ever he thinks is best. It dosn't need to be a pure Linux or Windows system.. Throw in Solarus, BSD, Mac and BeOs machines if the Sysadmin thinks it'll enhance the system.
You think Windows or Linux can do everything perfictly?
If so.. stay away from me...
Errr (Score:3)
Linux advocacy rises to match that of Microsoft FUD (in otherwords no better than)
Two wrongs do NOT make a right.. three make a uturn and four make a left..
Ok why should Slashdot ever post a Windows defect anyway?
On the other hand.. Go read the stuff on Windows websites.. Every Linux defect is published as proof Linux is poor defective etc etc etc.
Getting the facts straight..
Windows can be secure Linux can be cracked..
It's the SysAdmin that make it happen...
Software is just tools...
But never tell an auto repair profesional he must use the brand of tools you picked..
Same for SysAdmin...
If the SysAdmin prefers Dos he shouldn't be forbiden from using it if it can do the job.
(Some tasks are insainly low overhead and can run from a XT running Dos... very few...)
Do something constructive -- start using GPG! (Score:2)
The action plan is
- Generate a secret key. Use a strong passphrase, and keep it on a machine that you trust deeply. (Your own laptop or desktop.) Perhaps even keep it on removable media.
- Distribute the public key widely. Get other people to sign it, after checking your credentials.
- For all future releases of the software, either generate a detached signature, or put the MD5 signature into a GPG-signed release announcement.
- When you download software, check the signature before you install it.
This is not complete protection: there are still attacks involving breaking the signing machines, getting users to use the wrong public key, and so on. But if more projects started using this, it would be a real advance.Re:They should provide more details (Score:3)
Until we know, there is just as good a possibility that the site was "cracked" by someone leaking an important password, somebody walking up to one of the servers, an upset employee, the brother (or brother's friend) of someone who works admining the SourceForge project ("Hey, can I check my email?" "Sure"), or even a laptop swiped at E3 that had an admin SSH account preconfigured.
Don't assume that it's a technical problem... I've only had one and a half major successful breaks in security, and both were social, rather than technical problems. Plus the *very* common problem of cell phones, ISP and AOL accounts and such that are used for a few months past termination because HR didn't inform IT. Hell, we even had someone using our contact database (that's the half) because HR never told us, and he was running around with a company laptop and an (easily turned off) key disk.
--
Evan
Re:How Secure? (Score:2)
I guess I agree. Sourceforge is a wonderful idea and a generous service to our community, but the community evolved in a decentralized environment, and I'm not sure centralization is the way forward.
Of course, I don't think SourceForge was intended to be a centralization move. By all accounts they were somewhat surprised at the uptake on it.
> I run my own CVS server, and am about to pay a small amount ($10/m) for an ISP to host my hobbyist code. Granted, it doesn't have all the features of sourceforge, but I don't mind.
If enough people do that, a featureful system might well evolve for it. There's lots of free support code floating around, which a talented and dedicated party could probably forge into a nifty kit for small-site developer projects like yours.
--
Re:I'm kinda glad. (Score:2)
You would have a case if open source projects were more subject to hacks than clesed source projects.
The general evidence is that the opposite is true.
Re:I'm kinda glad. (Score:2)
In this arena there is no other type.
Re:How Secure? (Score:2)
Re:They should provide more details (Score:5)
Xix.
Re:open source myth (Score:2)
Right...because it never [securityfocus.com] happens [slashdot.org] to [slashdot.org] Microsoft [slashdot.org]. That's [attrition.org] very [attrition.org] clearly [google.com] known [google.com].
Re:The OS on sourceforge.net (Score:3)
216.136.171.196:80 * Novell Netware TCP/IP
I think 'queso' is wrong [netcraft.com].
Re:open source myth (Score:4)
I don't know what PHBs you're talking about, but all the PHBs I've ever met care only about reducing their dept's spending and increasing their dept's output. They most certainly are 'interested in why not to use Microsoft', and it's called money. But they don't think there is anything else out there that they could possibly use.
In the recent past, some of them have learned of this 'Lee-nooks' thing that they might be able to use instead of the oh-so-expensive Microsoft stuff! However, they're very cautious since 'no one was ever fired for buying Microsoft', and if Linux fails (many of them worry Linux and OSS may 'fail' as a concept, but in reality it's their deployment that might fail) then it's their ass for using it. Reports like this one do make them nervous about Linux, but only because they are worried that there's no comapny to blame when this happens (they think).
PHBs may be stupid but they can add and subtract. Unless it's relevant to their business, they care very little about 'uptime' (usually) or 'reliability' (usually), but stuff like 'price' and 'liability' they are very well aware of. Linux intrigues them with the price, but they are very worried about the lack of centralized liability. That's why Redhat is doing so well, the PHBs have to have someone to
Sign tarballs with a crypto hash (Score:2)
The BSD "ports" tree is very well designed for this. The MD5 sum is stored on *BSD mirrors, and the files are fetched from various locations (like Sourceforge) . When a port has to be built, the source code is fetched and compared with the awaited MD5 sum. If the sum differs from the computed one, a bigfatwarning appears and installation stops.
I guess Debian packages fetched through apt-get have something like this, too.
For other package or source code, put MD5 / SHA1 sums on another web site. But well... unfortunately in the real world, users will never check the sum.
And this doesn't protect the CVS tree from being trojanized. But the CVS tree is another story. When a developper types 'cvs update' or 'cvs commit' and discovers odd changes (for instance on the part he -and nobody else- is working), he can discover the trojan and reset the tree to a sane state.
In all cases, the open source world depends on trusted relationships. Sourceforge has the power to put trojans in all major open source projects and it would hurt a lot. The same thing goes for Tucows, Ibiblio.org, etc. Developers have to trust these free hosting services. End users have also to trust them. End users should also trust developers. There are many popular projects with only one developper, so nobody would review the code while an hidden trojan is making disaster.
But open source developers and hosting services are clean. Everybody is trusting each other. While any of them could create severe damage to the open source world, it doesn't happen. This is a question of mentality. On some commercial operating systems, trojans and viruses are common, and people never install new software without running an antivirus.
Re:I'm kinda glad. (Score:2)
I disagree. Not releasing the source code means that :
If you read Bugtraq [securityfocus.com] you will notice that Windows applications have tons of security holes. But the number of holes is not important. The important thing is that often, a security advisory ends up with "Vendor has been contacted... no response so far... no known fix... no workaround..." . And what can vulnerable users do in this case ? Nothing. Wait. Pray that nobody will see the breach. Wait until the vendor wakes up. If he ever does.
Also, remember that most closed-source encrypto schemes were hacked (decss, anyone ?) .
Yes, but not yet. (Score:2)
No sense in making it easier for the crackers. "Here's what's broken! We've just narrowed your list of 384 possible exploits to try down to one!"
No, not yet. I know some of the people working SF, they already know how to fix this sort of thing and don't need /. posters telling them how to do their job (including me *grin*). And if I were in their place, I would first fix the server, then fix the other servers that haven't been compromised yet, and only then announce what the problem was.
Geocrawler is going away. (Score:2)
Which is a good thing, since it's down for 8 hours every day doing magic things
--
WEll well (Score:4)
Re:They should provide more details (Score:5)
Will they be changing their name to ForgedSource, then?
Re:yes, well (Score:4)
Actually, I'm waiting to find out what the cause was.
Stupid admin errors happen both on NT and UNIX - they're not a feature of the OS.
Software problems are a different story. And we don't know which yet, so I'm waiting. Mostly. :)
Is published source safer? Perhaps. (Score:2)
This applies to both 'white hats' finding, reporting, and fixing the holes, and to 'black hats' finding, exploiting, and sharing the exploits.
In general, intentionally added backdoors in open-source software have a relatively short lifespan, while backdoors in closed-source products can live on indefinitely.
As I was quoted in a print magazine nearly a decade ago "The holes are already there, it's simply a matter of who finds them first".
One advantage of OpenBSD is that a primary goal of the committers is to pre-emptively find and fix problems that have the potential to be holes.
Single Point of Failure (Score:5)
Re:They should provide more details (Score:3)
cheers,
metric
Re:Care to back that up with facts? [OT] (Score:2)
Re:They should provide more details (Score:3)
Here's another link (Score:2)
J.S. Wurzler Underwriting Managers, one of the first companies to offer hacker insurance, has begun charging its clients 5 percent to 15 percent more if they use Microsoft's Windows NT software in their Internet operations. Although several larger insurers said they won't increase their NT-related premiums, Wurzler's announcement indicates growing frustration with the ongoing discoveries of vulnerabilities in Microsoft's products.
Re:Care to back that up with facts? (Score:3)
Windows 2000 secure? Yah, right... (Score:4)
Those graphs are very misleading, because they lump NT4 in with Windows 2000. It is widely known that NT4 had serious issues, which isn't surprising, since it was designed prior to the real internet explosion -- IIS was originally an add-on.
That's a ridiculous argument. Regardless of what it was originally designed for, Microsoft ended up selling NT4 as an Internet server OS. If, as you readily admit, it had serious issues, then why were they promoting it as a premium Internet-capable OS in the first place? Further, when the server technology changes again in the future (and believe me, it will), how can you possibly trust Microsoft to get it right given the mess they made of transitioning NT4 to the Internet and webserving?
Second, I should point out that Linux, and indeed every other Unix and Unix-alike, was designed before the 'real internet explosion' too. Indeed, if you trace back the lineage of 'proper' Unix, it was around when the internet was just being born, and many years before the arrival of TCP/IP, let alone HTTP. A webserver is still an add-on for most Unices and yet they seem to be able to cope quite adequately and securely with it.
Third, all the other OS stats combine current and previous versions of the OS together. Given that Windows 2000 is merely NT5, why should it get any different treatment?
Finally, go have a look at Attrition's website defacement stats for May 2001 so far [attrition.org] (although Attrition are no longer mirroring defaced websites, they are still compiling statistics on defacements). Here NT and Windows 2000 are treated separately. You will notice that although NT is by far the most defaced, Windows 2000 comes second with some 29.55% of all defacings (all this information correct at time of writing). This compares to a total of 8.99% of all defacings for combined versions of Linux. This is a quite remarkable achievement for Windows 2000, to achieve this in just 18 months since its release - over 3 times the defacement rate of Linux. Well done Redmond!
Oh yes, for those of you who need a reality check about market share in the webserver market, this is the latest Netcraft survey [netcraft.com]. Sadly, the statistics by OS are not available without paying Netcraft (come on, we know it's the SSL survey that you make money from, please give us some hard OS information for non-SSL sites). However, it would be conservative to assume that approximately 60% of all Apache sites run Linux, and that figure still gives Linux twice the market share of NT and Windows 2000 combined. If we make another very conservative assumption, that Windows 2000 is half of that combined Microsoft figure (the following figures get worse for Windows 2000 the lower that share is), then we get this rather amazing figure:
Taking even very conservative estimates, a Windows 2000 webserver is currently at least 12 times more likely to be defaced than a Linux webserver.
I think that says it all.
SSH key info on SF (Score:2)
This is a useless measure, as all that is stored in the authorized_keys files are the public key hashes, which cannot be used to compromise any other systems. (Not unless they get more data about the key or find a way to reverse the encryption, but I count that as highly unlikely.)
The only thing that could come out of having the public key hashes stolen is that we could maybe login to the systems of the bastards that hacked SF and get our revenge.
Thusly, SF has wasted a chunk of time for everybody by obliterating our public keys.
ICQ# : 30269588
"I used to be an idealist, but I got mugged by reality."
Re:yes, well (Score:2)
(C'mon, please? I've never had a law named after me before.)
Re:Huh? (Score:2)
It is a secret plot to chew up bandwidth! The bastards knew that the ensuing discussion on /. would foul up network traffic for hours!!
Seriously, though, think about the annoyance and loss of productivity for all of the people and projects that depend on sourceforge, not to mention the PITA that it will be for the sf admins over the next several weeks. This would NOT be the first time that a pissed off employee tried to screw his former employer...
-bluebomber
Re:I'm kinda glad. (Score:2)
No, not releasing the source would hide many security problems. Probably only temporarily.
-Gabe
Re:When it rains it pours. (Score:2)
Re:Huh? (Score:5)
But could you imaging though, if someone were to add/modify 4-5 lines off code and you didn't have another copy offsite? You would have to remember why every single line of code was there, you couldn't trust the comments telling you why this procedure is there.
For an example: It would be very easy to add code to add, "allow-anyone with this password to get a root shell" lines to a compromised box. Now lets say it's an ISP running an IMAP server they get off of Sourceforge, gets a new version. The program appears to run just like it's supposed to, they never would know that there is a 3 line, fork shell process code added into it. Being an ISP they have to have this program accessible to anyone anywhere, so they can't have this program behind a firewall. Along comes the wiley hacker who compromised the code to begin with... *poof* root shell on box.
That is the scary part, without being able to go back to a true "golden" state, EVERY single line of code has to be checked, without relying on possibly forged comments. Comparing MD5 hashes could tell you if the program has been modified, but some programs are modified hourly, most of these don't have checksum information.
I know who did it! (Score:2)
Re:They should provide more details (Score:2)
I'm not saying this is the case, I'm just speculating.
The OS on sourceforge.net (Score:2)
216.136.171.196:80 * Novell Netware TCP/IP
Coincidence ?
Re:yes, well (Score:4)
Well you set it up and tell it what you are doing. It installs all the software etc and sets everything up at the WORST possable setting."
I think someone [redhat.com] beat you to it.
Re:yes, well (Score:5)
As a side note, you're absolutely right. Security breaches are a fact of life on the Internet and no site is 100% secure. Just remember this the next time there's a story about a MS site getting cracked and try not to get all high and mighty about it because Linux, just like every other piece of software is NOT 100% secure.
At the very least... (Score:2)
They've already done more than what is the usual for most companies.
Re:Care to back that up with facts? (Score:2)
In contrast, Windows 2000 is much more secure and infinitely more stable out of the box than NT4. Of course there are some issues that need to be patched, but that's life.
Bottom line: don't try to mislead people by pretending that those numbers are for Windows 2000; most are a result of widely-known NT4 holes that admins haven't bothered to patch.
-------
-- russ
"You want people to think logically? ACK! Turn in your UID, you traitor!"
Re:open source myth (Score:2)
As far as features go, the ones that ensured we wouldn't be adopting Linux are: ACLs, Directory Services, and ease of use.
-------
-- russ
"You want people to think logically? ACK! Turn in your UID, you traitor!"
Did the root kit use any GPL'd software? (Score:3)
Re:The OS on sourceforge.net (Score:2)
For example, on Linux one can use something like ippersonality [sourceforge.net] to mangle the responses to potential fingerprinting attempts, and make your computer look like running another os. Too bad the authors haven't updated the code recently, the most recent version seems to be made for 2.4.0test4.
Oh my god! (Score:2)
Oh, wait.
Re:When it rains it pours. (Score:2)
Re:They should provide more details (Score:2)
Re:Did the root kit use any GPL'd software? (Score:2)
Re:Lets slow down a little, shale we? (Score:2)
Yes, of course I should remove everything except the apps I actually use... you've done that, right? Every time you want to play with / explore some new app, you install it from the CD, apply patches, and then carefully remove it when you're done with it, right? I *don't* think so :)
--
"I'm not downloaded, I'm just loaded and down"
Re:Lets slow down a little, shale we? (Score:2)
The problem is, I tend to forget to remove software; or rather, I never quite get around to deciding that I'm done evalling them. "Ooh, can't delete that just yet, I didn't ever get to grips with $feature..."
--
"I'm not downloaded, I'm just loaded and down"
Re:Repercussions and Security Theory (Score:3)
Art At Home [artathome.org]
Hmm... (Score:2)
As a user that hasn't used SourceForge for more than a week, this makes me a bit worrysome. I strongly hope that they used one-way, 128+ bit encryption on the passwords.
SourceForge is a very large operation. Remember that. No big operation is perfect, them included. Even RSA has been cracked (their website [attrition.org], rather.)
No operating system, not even our beloved Linux, is totally secure. It's only secure until the next bug is found. Remember, security is a concept.
Now, I have noticed there are some Windows zealots trolling Slashdot right now about the insecurities of the open source model, a la Microsoft. As a user of Windows 9x/NT, Linux, OpenBSD, FreeBSD, and a number of various other OSes, I can tell you right now that neither is more secure.
It only takes more time to find the holes if the software is closed-source. At least with open source, they're generally found quickly and patched quickly.
Neither closed or open source is more secure. And no OS is completely secure. Not Windows, not Linux -- not even BSD. Sorry!
Lets slow down a little, shale we? (Score:3)
But right now, we don't know anything about this attack. We don't even know if software is to blame. It could be a bad admin, it could be a buggy kernal patch, it could be someone sniffed an admin's root password while they unknowingly used a cracked copy of MS Terminal on a Windows box...
Until we know what actually happend we can spin it any which way.
Re:Repercussions and Security Theory (Score:3)
Since a private key cannot be derived from the public key [within a reasonable period of time, given an adequate key length], the public key would be worthless to anyone compromising the server. [As well, by doing this, you put the burden of security on the client. If a SourceForge patron does not adequately secure his/her private key, (or chooses not to participate... it could be an optional feature) then he/she takes the risk of having his/her password compromised, in the case of a server compromise.]
-jbn
Re:Huh? (Score:3)
Signed distributions don't really protect against this - you pretty much have to audit all the changes since the last distribution before security was compromised, assuming you know when security was compromised. If you don't know when, then it's probably wise to audit the entire source for your project.
The solution to this kind of problem does involve digital signing, though - digital signing of each code check-in by the author. This way you have accountability for each check-in, and you can just prune out all the "anonymous" check-ins. As long as you keep your private key safe on your dev box, compromises to the repository can't be undetectable (though they can go undetected if you're not looking for them).
I wonder how hard it would be to modify CVS to add a little delta-signing? Might not be possible if CVS uses reverse deltas (like most repositories do).
Basically you want to be able to run a utility on the source tree that verifies the identity of each check-in by cryptographically verifying an actual file hash signature of some sort. It would need to maintain a collection of the public keys used in signing to do this, so you need some key exchange protocol. In order to verify the signature of each check-in, we need to know what the set of data is for each check in. Typically it is a "delta" (basically the output of diff), or a set of deltas for a merge.
The problem with signing the deltas is, most modern systems don't keep the deltas. Instead, they update the "tip" with your changes (this is an optimization, since the tip is the most requested version (with the exception of our waitress the other day, who said "I don't want the tip, baby, I want the whole thing!")), and then generate "reverse deltas" which are applied to the tip version if you need to go back in time.
On the other hand, the forward deltas can probably be computed from the reverse deltas, so signatures on normal deltas could be verified with some computation. Alternately, the reverse deltas could be computed by the client (this is probably bad performance-wise) and signed.
Better yet, since we're client-server-ish with CVS, you could submit your changes, the server could hash the set of reverse deltas after it's computed them, send the hash back to you, and you could sign (encrypt with your private key) the hash and send it back.
That way, there is a quick way to verify who made each set of changes, without too much network bandwidth lost. To verify, the server can take the hash of the existing set of reverse deltas from a particular merge, then use your public key to decrypt the "signature" hash, and compare. If they are the same, then the delta files have not been tampered with.
The question with this approach is, how do you protect the tip? In a reverse delta system, protecting the deltas is only half the battle (well a lot of things are half the battle! Losing is half the battle!) If you can't verify the authenticity of the tip, then an intruder can modify the tip and not touch the deltas, and you couldn't detect it. That's bad. I think in order to protect the tip, in addition to signing the hashes of the deltas, you should also sign a hash generated from the full and updated versions of all the files you touched with your merge. This way we should be able to verify both the tip versions and all the deltas, and have some accountability (we can associate 'nyms with each public key we have).
Sounds like you would need to alter the pserver protocol, add some hashing to the post-merge processing, and update the clients with some GPG code so they could sign hashes.
Any volunteers? ;)
Phil
yes, well (Score:2)
No, they should not provide more details (Score:2)
No, they should not provide more details until they have the situation under control and have completed their forensic audit of the intrusion.
When a system is cracked, basic OS binaries can be replaced with one that does the same function except it will now have a backdoor. And since we're talking about Linux platforms, with rapidly mutating code, it may be difficult to completely root out the compromised binaries. It can even be as simple as a subtle permission change on a device file or subdirectory.
Someone else also mentioned that the CVS trees for projects could be compromised! And remember that a clever cracker could have compromised the system months ago without attracting attention; that could mean the backups are compromised as well. Add rebuilding "n" platforms from scratch (the only way to ensure the platform is trojan free), we're talking about a week or two of work, without even factoring in the time for the forensic investigation!
A complete report of all details to the users (without completing the analysis and securing the platforms) informs the hacker to the progress in securing the systems and if a hole was left behind. Only debriefing the project owners is still not a reasonable option; the hacker could be someone that has a project in sourceforge.
I hope they got some security heavy hitters to look into this and didn't decide to handle it in-house.
That's open source security for ya... (Score:2)
This is NOT flamebait.
Now, let's wait for them to post how it was done, like Apache did.
Open Source Security isn't infallable... but at least we know why when all's said and done.
You are correct (Score:2)
Not necessarily (Score:2)
They should provide more details (Score:5)
So, why not let the legitimate Sourceforge users have a bit more information about what happened? Perhaps some of the users might have an idea for a fix, or at least a way to protect their own work. Heck, we don't even know the nature of the breach, do we? Was data stolen? Corrupted? What? Inquiring minds have a legitimate need to know.