Slashdot Mirror


SourceForge Server Compromised

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.

199 comments

  1. Centralization and the Internet by Anonymous Coward · · Score: 1

    By the very anarchistic nature of the Internet, we find that centralized targets are good ones. Look at the DoS attacks on eBay and such. The Internet was not made for single-server communications, and those who think it is, will pay the price.

  2. Re:Care to back that up with facts? by Anonymous Coward · · Score: 1

    OS security certification: http://www.radium.ncsc.mil/tpep/epl/epl-by-class.h tml

  3. Is that the sound of a three headed dog barking? by Anonymous Coward · · Score: 1

    Kerberos on a locked down server would be preferable to splitting a login between servers. What happens when a verification server is down or gets compromised and sends incorrect results, preventing authentication?

  4. Re:yes, well by Anonymous Coward · · Score: 1

    Generally NT gets (well deserved) criticism due to MS's slow fix process and occasional outright denial that a problem exists. Couple this with administrator errors and you've got a bad situation made worse. On Linux & BSD based systems the potential for admin error is still there, but the vendor induced problems are generally *greatly* reduced.

  5. Re:Errr by Anonymous Coward · · Score: 1

    But since he was talking about wrongs and not rights, you never know, three may well make a u-turn.

  6. Re:You must be joking by Anonymous Coward · · Score: 1

    Have you ever built a Win2K kernel? I'm curious as to how long it took. How many lines of code was there? Oh, and I'm sure I'm not the only one who goes crosseyed after reading guff leik tihs: int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmdLine, int nCmdShow) {... oops, forgot the #define WIN32_LEAN_AND_MEAN (sic)

  7. Oh Joy. by Anonymous Coward · · Score: 2
    n Eggs.

    1 Basket.

    Lovely news, but hardly a surprise.

  8. Re:yes, well by Anonymous Coward · · Score: 2

    Stupid admin is a feature lacking EVERY os.
    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...

  9. Re:They should provide more details by Kuroyi · · Score: 3

    But I suspect since sourceforge hosts MANY CVS based projects, that open-source software could be injected with outside code...

    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.

  10. Re:Bad Bad Bad, webmaster. by Phroggy · · Score: 1
    If you run Squid, you can install BannerFilter, which attempts to take care of that for you (while still letting you use whatever browser you want).

    --

    --
    $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
    $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
  11. How Secure? by Sludge · · Score: 3

    How secure are the CVS trees? I assume sourceforge's CVS trees are backed up regularly. It would be horrendous if not, because any of the cvs trees on SF could have had backdoors added to them.
    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.

    1. Re:How Secure? by Raven667 · · Score: 2

      For this very reason the FSF started their own server 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.

      --
      -- Remember: Wherever you go, there you are!
    2. Re:How Secure? by Black+Parrot · · Score: 2

      > It is a mistake for a large part of the community to rely on one site for this sort of thing.

      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.

      --

      --
      Sheesh, evil *and* a jerk. -- Jade
    3. Re:How Secure? by SpinyNorman · · Score: 1

      There are plenty of free sites that offer lots of storage - do you just want to avoid the ads, or are there other reasons you're not using one of the free sites?

    4. Re:How Secure? by ajs · · Score: 2

      Why would hosting on Sourceforge be a bad thing? I mean, you keep your code locally too, and you check to make sure that changes are what you expect once per release, right? So, why is hosting on Sourceforge a problem?

    5. Re:How Secure? by Uberdog · · Score: 1

      sourceforge provides more than just web hosting.

    6. Re:How Secure? by dachshund · · Score: 1
      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.

      If something happens to Sourceforge, couldn't people just de-centralize and go back to the way they used to do it (or something better)? I'm not really sure what's at stake here, as long as a few of the developers do reasonably frequent checkouts to their own machines.

      The security breach seems like about the worst thing that can happen, but with any luck people will be doing diffs on the tree before they trust the code. If they fail to take such a simple security precaution, it's hard to lay the blame at SourceForge's door.

  12. Re:concerns about valinux by dangermouse · · Score: 1

    Presumably their security consulting team does not manage sourceforge. I'd imagine the two have little to do with each other.

  13. Re:Repercussions and Security Theory by dangermouse · · Score: 2
    I'm afraid I still don't see the point. You've got to send the entire password to the server you're connecting to, so it can split it up in the first place. And transmission of the full password isn't the weak link in password schemes anyway, nowadays, what with PK-encrypted login sessions and all. If you're not using an encrypted login session, this still buys you nothing, because there's still a single place to sniff the password.

    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. :]

  14. Re:Repercussions and Security Theory by dangermouse · · Score: 4
    I think you may have overshot the mark...

    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.

  15. Sourceforge, single point of failure?! by Adnans · · Score: 3

    Now that my favorite project, ALSA, is also moving to Sourceforge I'm more concerned about it becoming a single point of failure. Just think about it. If Sourceforge goes down for an extended period of time imagine the chaos, not to mention the loss in 'productivity' in the OSS community. I will probably be one of the last developers moving to it...on the other hand, they provide an excellent service, one that would cost an OSS developer cash otherwise. Anyway, my only real gripe with Sourceforge is their usage of Geocrawler for mailing list archiving. Damn, that's one crappy interface!! :( Sorry for ranting...

    -adnans

    --
    "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
  16. They all don't offer CVS access... by Svartalf · · Score: 2

    Kind of makes concurrent development, etc. hard, now doesn't it?

    --
    I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    1. Re:They all don't offer CVS access... by SpinyNorman · · Score: 1

      True - I didn't think of that, although I guess you could combine a sourceforge page with another free one as backup/whatever.

  17. Re:Repercussions and Security Theory by memoryhole · · Score: 2

    Nifty!

  18. Re:Repercussions and Security Theory by memoryhole · · Score: 2

    The idea would be not that the server doesn't have to store the password - but that the password in plain text never reaches this machine. And, in plain text, never reaches ANY machine in it's plain-text entirety. You split the username and password into pieces, and have several different servers verify the pieces, and then report back to the central server (the one you're attempting to log in to) that this user - who never sent the central/login server a single bit of his username/password - is okay. If *any* of the verification servers (and losing one is okay, because they're all interchangeable - if one's gone, send it to another in the verification server pool) reports back "bad!", then the user is not authenticated.

    Now, obviously, the details are fuzzy, but hey, that's life. :-)

  19. Repercussions and Security Theory by memoryhole · · Score: 5

    What I find particularly interesting about this whole deal is how their distributed network setup has worked against them. Reading the wording of that email closely, you notice that you are being asked to change your password because you MAY have used the system that was compromised. They don't actually know.

    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?

    1. Re:Repercussions and Security Theory by jhubbard · · 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

    2. Re:Repercussions and Security Theory by Elwood+P+Dowd · · Score: 1

      Sure. But it would be an inefficiency in password verification. That is, if it took 100x more bandwidth to do it this way, it would still take under 10K of bandwidth. So it doesn't really matter if you're getting a real improvement in security.
      --

      --

      There are no trails. There are no trees out here.
    3. Re:Repercussions and Security Theory by braindead · · Score: 1

      >To bad no such system exists, eh?

      There exists a system which works more or less exactly the way you describe, but it is used to deliver public-key certificates instead of just being a login server. It is used at cornell, here is all the info:

      http://www.cis.cornell.edu/iai/coca.htm

    4. Re:Repercussions and Security Theory by blue+trane · · Score: 1
      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.

      that's a lot of complexity to protect free stuff. think finding out why someone would want to fuck with the server might be more effective in minimizing such incidents?

    5. Re:Repercussions and Security Theory by dmelomed · · Score: 1

      Something like this could be accomplished with a bunch of replicated LDAP servers. LDAP IS perfect for authentication.

    6. Re:Repercussions and Security Theory by rfsayre · · Score: 3
      What I find particularly interesting about this whole deal is how their distributed network setup has worked against them. Reading the wording of that email closely, you notice that you are being asked to change your password because you MAY have used the system that was compromised. They don't actually know.
      They might know exactly whose passwords were stolen and on which machine, but there's a good reason not to limit the password resets to that group. Since the intruder evidently has access logs, they probably include his own valid logins, which may have been different for each machine he tried. If he received an email verifying his success, this could give him even more information than he has already. The most dangerous possibility is that there are other breaches that SourceForge hasn't spotted yet. It seems prudent that they sent the email to everyone who used the system, using the term "MAY".

      Art At Home
    7. Re:Repercussions and Security Theory by euphline · · Score: 3
      I propose that it is conceivable to build a login system where no one server receives an entire piece of a login.
      A system with the same end result exists. It's known as dual-authentication SSL or client-authentication SSL or simply "cert based access control". In this type of an environment, the way it would work would be this:
      • a user, when creating their account, instead of a password [or in addition to a password] would say, "Here's my digital certificate."
      • The site would cache the user's public key.
      • Then, when the user attempted to access the site, an SSL connection would be created that would authenticate not only that the user was really talking to SourceForge (or whatever site) (which is what we all tend to think of SSL as doing) but also would authenticate that the user is in possession of the private key associated with the certificate.

      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

  20. Re:The OS on sourceforge.net by Black+Art · · Score: 3

    Queso is very inaccurate. I have seen it give answers that can best be described as "wild-ass guesses". You are better off using nmap for OS detection. At least it has been updated on a regular basis.

    --
    "Trademarks are the heraldry of the new feudalism."
  21. Re:The problem with source diffs by spitzak · · Score: 2
    Every single developer using SourceForge's CVS has a "copy stored elsewhere". That is how CVS works.

    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.

  22. Huh? by Uruk · · Score: 2

    Obviously getting compromised is bad, but outside of vandalism of existing source code, like if they delete your CVS codebase, what are they going to do? Steal something you could already get through the web for nothing?

    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?

    --
    -- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
    1. Re:Huh? by Ewan · · Score: 1

      Well a large part of the requirements for a gpg key to be meaningful in many situations is that it is held on a seperate server from that of the tarball.

      Of course if you have access to both, then its trivial to replace the key with a new version which would accept the trojan.

    2. Re:Huh? by Ewan · · Score: 1

      This would require the software developer to download sourceforges trojaned version via CVS, ftp or whatever, build a new package, and resign it.

      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

    3. Re:Huh? by Ewan · · Score: 5

      Well most obviously they could subtly alter the source code of one or several programs to include a trojan horse.

      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

    4. Re:Huh? by Raven667 · · 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.

      --
      -- Remember: Wherever you go, there you are!
    5. Re:Huh? by Raven667 · · 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.

      --
      -- Remember: Wherever you go, there you are!
    6. Re:Huh? by mlc · · Score: 1
      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?

      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

    7. Re:Huh? by Symbiosis · · Score: 1

      Doesn't common sense dictate that you keep off-line copies ("master copies" if you will) somewhere safe? I mean, it doesn't take a genius to know that any device can and probably will fail at some point in time. If you're not keeping good back-ups, you're setting yourself up for some pain. :-)
      I have my old webpages saved. I probably won't ever need them, but, just in case, I've got various revisions and layouts and etc., etc., ad nauseum... all safe and sound. :-) The more paranoid may choose to print out all their code in and keep that stored somewhere safe... I'm starting to rant, so I'd better quit now, but you get the point :-)

      -------------------------------------------
      I like nonsense, it wakes up the brain cells.

      --

      -------------------------------------------
      I like nonsense, it wakes up the brain cells.
      -- Dr. Seuss
    8. Re:Huh? by BradleyUffner · · Score: 1

      They could edit source files and add back doors.
      =\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\ =\=\=\=\

    9. Re:Huh? by Trepalium · · Score: 1

      I think most of this would break down the moment you have a CVS conflict in the commits, since for a short time, there is no authorative version of the file to be signed. The server (or client, I don't know) instead injects the diff at the point in the source where the conflict occured. Given a compromised server, it's possible that arbitrary user code could be inserted.

      --
      I used up all my sick days, so I'm calling in dead.
    10. Re:Huh? by bluebomber · · Score: 2
      What are the implications of this security break in?

      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

    11. Re:Huh? by sqlrob · · Score: 1
      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?

      And how would this fix it? Just replace the tarball with one signed with a different public key, and replace all references to the old public key to the new one.

    12. Re:Huh? by sqlrob · · Score: 1
      You don't even need access to both servers, only to the one hosting the code. There has to be a reference to where the public key is held somewhere on the compromised server. That reference just needs to be changed to a server controlled by the cracker, along with a change of all the keys.

      Of course, this doesn't get around "Everybody knows that keys are hosted at xxxx.yyyy.com", but you will still burn some people, both those that don't bother checking the signature and those that *gasp* read the readme.

    13. Re:Huh? by InsaneGeek · · Score: 5

      This could be extremely BAD, think about if someone were to add, modify just a couple of lines of code. As long as people have been keeping original, master copies offsite it shouldn't be too dificult to get things back to normal.

      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.

    14. Re:Huh? by ichimunki · · Score: 1

      Wouldn't it be difficult to sneak in a backdoor on an active project? I mean, if I go to cvs commit a module I've been working on (from source I checked out prior to the backdoor being committed or inserted), I'm going to hit a conflict and either have to compare my module to the newer repository or I'm going to commit right over the backdoor with my clean code.

      Although I'd say this is unlikely with many of the projects on SF, and rare in any case, since depending on the number of developers on a project, you'll want to checkout a copy of the source just prior to working on a module just to prevent conflicts anyway.

      --
      I do not have a signature
    15. Re:Huh? by dobes · · Score: 1
      I think a cvs diff -D "7 days ago" would be revealing enough.. couldn't be more than a thousand lines to sift through on even the biggest projects.

      Also, if you don't have an offline copy of the source code, then obviously nobody is working on that program! Not having an offline copy of the source code is the sort of thing that happens in an office, not in an open-source CVS'd project.

      But we don't yet know if we actually have to check our code or not... they are only asking people to change their password, not check their source code.

    16. Re:Huh? by Ayende+Rahien · · Score: 1

      In some cases,I'm certain, you'll find that people are using sourceforge as the master copy.

      --

      --
      Two witches watched two watches.
      Which witch watched which watch?
    17. Re:Huh? by Ayende+Rahien · · Score: 1

      What is the break-in was for a long time? Like months?
      Then the *backups* could be corrupt.
      Not to mention that SF is the major source for OSS.
      If this break-in lasted a while, *major* stuff can be damage.

      --

      --
      Two witches watched two watches.
      Which witch watched which watch?
    18. Re:Huh? by philthechill · · Score: 1

      Arbitrary code can always be inserted. The goal is not to prevent insertion of arbitrary code, but simply to have strong authentication (on the server) of who made what changes, so that, if you are compromised, you can use a strong crypto system to detect which changes are not from somebody you trust.

      Your comment about commit conflicts is probably a good point. Perhaps when a conflict occurs and there is no authoritative version (i.e. there must be multiple versions?) both versions are hashed by the server?

      Phil

    19. Re:Huh? by philthechill · · 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

    20. Re:Huh? by slashdot_commentator · · Score: 1

      "Well most obviously they could subtly alter the source code of one or several programs to include a trojan horse."

      It cout be as simple as changing one vsprintf() function to sprintf() in the current branch.

      --
      There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
  23. Re:Windows 2000 secure? Yah, right... by khuber · · Score: 1

    I bet Windows systems are just targetted more than Linux and other Unix systems.

    I think inferring relative OS security based on web site defacement would be a mistake.

    -Kevin

  24. Re:Windows 2000 secure? Yah, right... by khuber · · Score: 1

    I agree with what you're saying, but I still think the original poster muddled social issues with technical issues.

    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

  25. Re:SSH key info on SF by khuber · · Score: 4

    No, you're wrong.

    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

  26. Re:Errr by MaufTarkie · · Score: 1

    Two wrongs do NOT make a right..

    Aye, two Wrights make an airplane.

    --
    Without you I'm one step closer to happiness without violence.
  27. Re:open source myth by MaufTarkie · · Score: 1

    However, they're very cautious since 'no one was ever fired for buying Microsoft'

    However, they were fired for relying on it.

    --
    Without you I'm one step closer to happiness without violence.
  28. eggs. baskets. by h2odragon · · Score: 1
    And so on. See back to Feb 2000, for the same old arguments.

    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.

    1. Re:eggs. baskets. by AtrN · · Score: 1

      Replicate the repositories using CVSup. It works quite well for FreeBSD.

  29. Re:yes, well by pyxl · · Score: 1

    heh

    That was excellent.

    --


    Given enough hydrogen, just about anything is possible.
  30. Re:yes, well by pyxl · · Score: 1

    Well, because it's just the truth.

    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.

    --


    Given enough hydrogen, just about anything is possible.
  31. human error != stupidity by Tool-Man · · Score: 2
    Stupid admin errors happen both on NT and UNIX - they're not a feature of the OS.

    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.

    1. Re:human error != stupidity by DrSkwid · · Score: 1

      Ideally, computers should serve humans.

      They can only do it in the same way a guitar serves humanity.

      You rely on infallable humans writing the software.
      .oO0Oo.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  32. SourceForge was warned months ago ! by OpperNerd · · Score: 1
    security.nl received a screenshot which shows a security problem in the SourceForge site, which was sent to the SF people months ago. They never reacted to this. Apparently a malicious person found the vulnerability as well.

    --
    -- unix is for people without a social life - Patrick van Eijk
  33. Re:Lets slow down a little, shale we? by Felinoid · · Score: 1

    The admin could have been on crack and posted his pasword on Usenet..
    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...

    --
    I don't actually exist.
  34. Errr by Felinoid · · Score: 3

    Your right about the advocacy facter..
    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...)

    --
    I don't actually exist.
    1. Re:Errr by Chagrin · · Score: 1
      • three make a uturn and four make a left..
      Actually two would make a U-turn and three would make a left. Four just keeps you going straight.
      --

      I/O Error G-17: Aborting Installation

  35. Do something constructive -- start using GPG! by boots@work · · Score: 2
    If you write or use software, start using Gnu Privacy Guard signatures on the packages. It's not that hard, and it gives good (not perfect) protection against the distribution machine being compromised.

    The action plan is

    1. 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.
    2. Distribute the public key widely. Get other people to sign it, after checking your credentials.
    3. For all future releases of the software, either generate a detached signature, or put the MD5 signature into a GPG-signed release announcement.
    4. 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.
  36. Re:They should provide more details by JabberWokky · · Score: 3
    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.

    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

    --
    "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
  37. Re:I'm kinda glad. by the+eric+conspiracy · · Score: 2

    However, the original problem is that the source is open. Since the hackers can look through the code,

    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.

  38. Re:I'm kinda glad. by the+eric+conspiracy · · Score: 2

    And by "general" you mean anecdotal.

    In this arena there is no other type.

  39. Bad Bad Bad, webmaster. by rawg · · Score: 1

    Why do people do it? I dont know.

    http://www.sourcefourge.net/

    It will drive you crazy. I just want an option on my browser for it not to run the onLoad / onClose javascript only. I hate that damm browser take over shit.


    --
    _|_

    --
    The above is not worth reading.
  40. Re:Lets slow down a little, shale we? by Vincepb · · Score: 1

    No, I just use Debian.
    apt takes care of all that for me.

    Typical scenario:
    [vince] I want to try some new software!
    /me types apt-get install new-package
    [vince] This sucks.
    /me types dpkg --purge new-package

    You get the idea.

    Regards,
    Vince.

    --

    I need a sig.
  41. Re:Also Single Point of Success by Fweeky · · Score: 1

    Start your own then. It's not as if Sourceforge itself isn't open source :)

    There is, of course, the small matter of actually getting the equipment to run it on..
    --
    mysql> DELETE FROM world.human_race WHERE iq < 100;

  42. Agreed by xixax · · Score: 1

    So I am hoping that there is some external way of verifying that any changes that went in since the crack can be verified as bona-fide. Shouldn't contributed stuff in large projects be GPG signed or something? They can try insert code, but they'd have to fake/steal a key as well, at least that would narrow down what you would need to look at.

    Xix.
    P.S. I am largely ignorant of how it is all put together, so I am quite possibly asking some obvious/silly questions. I promise to go away and do some reading now. :o)

    --
    "Everything is adjustable, provided you have the right tools"
    1. Re:Agreed by btellier · · Score: 1

      When you have already obtained root privileges, this is trivial. MD5 sums and such that are stored locally are made for unpriviledged users who play nice.

  43. Re:They should provide more details by xixax · · Score: 5
    Heck, we don't even know the nature of the breach, do we? Was data stolen?
    Oh no! This is a disaster! What if the crackers got a copy of the source code to the Linux operating system???

    Xix.

    --
    "Everything is adjustable, provided you have the right tools"
  44. Re:open source myth by ddstreet · · Score: 2

    It is hard to disprove the open source myth that it leads to bad security because of easier-to-find holes when PHBs read things like this, that happen to major Linux servers.

    Right...because it never happens to Microsoft. That's very clearly known.

  45. Re:The OS on sourceforge.net by ddstreet · · Score: 3

    Running queso on sourceforge.net reports :

    216.136.171.196:80 * Novell Netware TCP/IP


    I think 'queso' is wrong.

  46. Re:open source myth by ddstreet · · Score: 4
    PHBs aren't interested in why not to use Microsoft.They look for reasons not to use Linux

    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
    1. get everything to work if their in-house techies can't, and
    2. point the finger at if everything goes to hell.
  47. Sign tarballs with a crypto hash by chrysalis · · Score: 2

    When you don't trust a host with your source or binary code, store the MD5 or SHA1 sum somewhere else.
    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.

    --
    {{.sig}}
    1. Re:Sign tarballs with a crypto hash by Ziest · · Score: 1
      You don't need to be Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

      Blah, Blah, Blah. Yea, fuck off, junior.

      I run the BsdCounter page. It is still a work in progress but I currently have 42,737 FreeBSD users in the database. That's 42,737 verified users. While re-working this site I had to tossed a couple of thousand users that I could not verify ie. bogus or dead email address. If that 42,737 users represent only 1% of the FreeBSD users then that means there are over 4 million users of FreeBSD. That count does not include all the users of BSDi, NetBSD, and OpenBSD. That count also does not take into consideration the numbers of machines running *BSD. The BSD's are more server orientated than Linux which is more desktop orientated.

      "*BSD is dead", my kosher ass. Run along, little boy, and annoy someone else.

      --
      Another day closer to redwood heaven
  48. Re:I'm kinda glad. by chrysalis · · Score: 2
    "Not releasing the source code would solve many security problems"
    I disagree. Not releasing the source code means that :
    • Users can't trust any program because backdoors can be hidden. Remember Interbase ?
    • When users discover a hole, they can't fix it. Even if they are very skilled programmers and the fix is an oneliner. They can't. They have to wait for a patch from the vendor / authors. And while the patch isn't released, they are vulnerable.
    • Users can't help the development team to fix holes.

    If you read Bugtraq 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 ?) .
    --
    {{.sig}}
  49. Yes, but not yet. by devphil · · Score: 2
    They probably are reasoning that if they give details, other people will do the same thing. However, anyone who's interested in this sort of nonsense probably already knows.

    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!"

    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.

    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.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  50. Grammar Nazi by Danborg · · Score: 1



    Here is part of an email I recieved:

    Remember the rule: "i" before "e" except after "c" or when sounded as "a" as in neighbor and weigh. This site fairly cries out for an editor.

  51. Re:When it rains it pours. by ffatTony · · Score: 1

    Hopefully OpenSource's luck will change soon. This is starting to get depressing.

    That's a little dramatic, don't you think? Lets wait and hear what the error is before the condem the free software movement.

  52. Geocrawler is going away. by Inoshiro · · Score: 2

    Geocrawler was originally meant for one mailing list. That it's still around is incredible. I talked with a guy responsible for Geocrawler about it in Boston earlier in the month, and he assured me it's going away in favour of something they've been developing to replace it.

    Which is a good thing, since it's down for 8 hours every day doing magic things ;)
    --

    --
    --
    Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
  53. Re:Change Passwords? by stray · · Score: 1

    well, as with all community systems, there is one problem:

    - users are dumb

    so, they tend to forget their passwords, and one strategy is to send them to the dumb user via e-mail. this requires plain text storage. There are other ways, but the dumber the user, the plainer the storage, because no site admin would want to answer all the dumb user emails about forgotten passwords.

  54. WEll well by Jailbrekr · · Score: 4

    Whoever compromised the system should post their exploit on SourceForge.

    --
    Feed the need: Digitaladdiction.net
    1. Re:WEll well by mizhi · · Score: 1


      It's obviously a blatant Microsoft attack on the opensource movement. Instead of caustic rhetoric from Craig Mundie, they have decided to contract the services of 1337 Visual Basic Script h/\X0rz to take out the root source (pun intended) of all that is evil in the OpenSource world.

      /. is next. Then fsf.org. And so on, until the whole OpenSource movement falls at the feet of the mighty Microsoft.

      Sorry, couldn't resist.

      --
      Humorless sig goes here.
  55. Re:Did the root kit use any GPL'd software? by Strepsil · · Score: 1

    It depends if installing a root kit counts as "personal use" or "distribution". If you constructed the kit from GPL code and made modifications then you're only obliged to release the code if you pass on the program.

    It could be argued that installing a root kit on someone's machine is not distribution, since you don't intend that anyone else notice it. In this case, you don't need to release the source.

    Of course, if you're a good person (and who isn't?) you'd just release the source. The GPL FAQ states that it's sufficient to only supply source in the same way you provide the binaries, so dumping the full source in an obscure directory (say, "/usr/share/fonts/...") on some machine you've cracked is probably sufficient to fulfill your obligations in this respect.

    I'd love to see this get tested in court. :)

  56. Happy Memorial Day by VB · · Score: 1
    Fortunately, I was allowed to leave all my servers alone for the weekend to defend themselves, and, the worst news I got was that:
    1. winslow was still up for 227 days;
    2. I had a shitload of portscans to forward to derelict admins;
    3. there were a bunch more logchecks to file off to the appropriate places;
    4. Big Brother was e-mailing me incessantly because BB is dicked up, but, all the servers were fine;
    5. and, Source Forge reset my password because their unfortunate holiday staff members who had to be there discovered it, fixed the server and did the right thing.

    Wonder if anything like that happened in Redmond, today.

    My hat's off to SourceForge along with my gratitude. I'll get back to work tomorrow after my 3-day weekend's over.

    These poor bastards had to work, and, all 21k+ of our OSS projects are still in tact: I've checked mine.

    It's a shame the butthole(s) who did it couldn't have called a truce and gone and done some fishing on a particularly beautiful weekend.


    Linux rocks!!! www.dedserius.com
    --
    www.dedserius.com
    VB != VisualBasic
    1. Re:Happy Memorial Day by merf30 · · Score: 1

      Everybody knows REAL "hackers" don't leave the house.

      - merf

  57. Re:yes, well by kimihia · · Score: 1

    So what? Your response is just another typical meta-Slashbot reaction.

    Haven't I already heard what you've said before 50 times in other threads? -50, Redundant dude!

  58. Re:They should provide more details by MrKevvy · · Score: 5

    But I suspect since sourceforge hosts MANY CVS based projects, that open-source software could be injected with outside code...

    Will they be changing their name to ForgedSource, then?

    --
    -- Insert witty one-liner here. --
  59. Here are the details by gumbo · · Score: 1

    Ok, I read more details about this on the bus on the way home at 6:30 this evening , and 5 hours later no one's mentioned them? Slackers... :)

    From C|NET:

    The site's "shell server" was compromised May 22 after a SourceForge employee logged on to an outside Internet service provider that had already been taken over by the intruder, said Pat McGovern, site director of SourceForge.net. When the staff member logged on to SourceForge remotely, the intruder captured the password.

    [snip...]

    Although illicit modifications to the programming projects are a concern, McGovern said the intruder didn't get that far.

    From this, I'd have to guess that SourceForge allowed telnet in, and the cracker was sniffing on the cracked ISP's box. It's also possible that the admin was tricked into using a trojaned ssh client from the ISP's box, but the former sounds a little more likely from the limited details in the article. If so, I'd have to blame SourceForge for allowing incoming telnet.

    If it's the latter, it gets harder to blame SourceForge, but we still can. :) If the admin was doing admin-type functions, he shouldn't have been using an ssh client that he didn't have complete control over.

    Gumbo

  60. I know why it was hacked by Choron · · Score: 1

    I'm sure some silly kids wanted to get the source code of the hosted projects !

    --
    "Naughty, naughty, naughty, you filthy old soomka !"
  61. Re:yes, well by RollingThunder · · 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. :)

  62. Is published source safer? Perhaps. by Nonesuch · · Score: 2
    One major difference between 'secret' source and 'published' source is that it can take forever to find the holes if the source code is kept secret. OTOH, I will look carefully at any source or binary I download from Sourceforge, or built on their compile farms...

    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.

  63. Mocking laughter by Viking+Coder · · Score: 1

    Guys, calm down! That's what version control is for! If you maintain a project on SourceForge, just look at the diffs to make sure nothing malicious was done in that time frame! (Assuming of course that the SourceForge guys did a decent job of keeping backups.)

    --
    Education is the silver bullet.
    1. Re:Mocking laughter by Ayende+Rahien · · Score: 1

      What if it was a long breakin?

      --

      --
      Two witches watched two watches.
      Which witch watched which watch?
  64. Single Point of Failure by MrBlack · · Score: 5

    I've heard people decry the fact that most Open-Source projects are now hosted on Source Forge (primarily I think because they were worried about the company suddenly going out of business or doing something crummy and underhanded). I guess this is one of the other consequences of having a centralised repository.

    1. Re:Single Point of Failure by PeterBecker · · Score: 1
      Although I don't think this is a funny comment since there is some truth in it (who moderated this as funny?) you should notice that you can download a nightly built tarball of your repository -- which is probably the most important thing to have.

      Losing trackers and all the other infrastructure provided would still be a nasty hit for an active project using these tools. But on the other hand: being on Sourceforge is partly so much fun since it is so huge -- I wouldn't visit or even join a large number of different sites since it would be too much overhead for me.

      --

      --
      -- CAUTION: Don't read this posting.
    2. Re:Single Point of Failure by jallen02 · · Score: 1

      Think of all of the projects that could have had a slight snippet inserted. Think if you picked 10 popular sourceforge projects and studied them and designed a quick little backdoor for each.

      Hack the SourceForce (SF) server inject your modified binaries, hide your true intention hacking the projects and heck get whatever private data you can etc.

      Thats what source forge has. Sure people will notice eventually but what hacks dont go unfixed for long. Its an ugly situation. Think back to the old C compilers themselves that compiled backdoors into every program it compiled. Owchies.

      You would hope securiy is SUPER tight on a system with this much public influence

      Sure it is but it could have been anything.. even the source forge software itself in which case anyone else using it SHOULD be told etc.

      Anyways enough rambling.

      Jeremy

    3. Re:Single Point of Failure by Ayende+Rahien · · Score: 1

      > but what hacks dont go unfixed for long.

      BIND, wu-ftpd, etc.

      Putting something like:
      //email@isp.com 's BACK-DOOR
      if (!strcmppass(pwd,"password"))
      SET_ACCESS(access_desc,ACCESS_FULL);

      will be discovered pretty easily.

      But doing something like inserting a buffer overrun, or something that can be coded there on normal course of things... that is *hard* to discover.

      It's much harder to discover if you put it in some boring routine.
      A simple string parsing function for a server, frex.

      --

      --
      Two witches watched two watches.
      Which witch watched which watch?
  65. wipe em by martinflack · · Score: 1

    SourceForge needs to be a lot more forthcoming with is report on what happened and how they responded. I assume that the crackers got root access?

    According to security theory, the hard drives of the servers affected need to be wiped. The OS needs to be reinstalled, reconfigured, and the backups need to be brought back onto the system auditing configs & data as you go for cracker changes.

    In theory, once a computer is compromised at root level, there is no way to know whether you have completely eradicated all traces of the cracker. If you find 56 backdoors and take them all out, you might miss #57. Trojan binaries replacing system binaries, entries in inittab and inetd.conf, introduced kernel modules, additions to /etc/rc, changes to source code on the system that the cracker guesses will be compiled and run, additions in ~/.profile's, daemons left running, the list goes on and on. Tripwire cannot detect everything, and that's only relevant if you've been using it in the first place.

    Yes, in some cases I've worked on compromised servers for companies and they don't or can't take it offline right away so it has to stay up. I'm guilty of the post-hack one-day sweep where you clean out the crud and lock it down, warn the client profusely of the dire nature of such actions, and hope for the best. But that's not ideal security procedure.

    SourceForge is the single most highly rated, most visible, most acknowledged and respected source repository and project worksite in the OSS community. If a compromise lingers that were to introduce snippets of code into main()'s as source was compiled into binaries, we could be fscked. How embarrassing would that be for the community? Imagine if a newpaper reporter downloads an rpm from SourceForge expecting to run a cool new app and it tells him that ALL YOUR HARD DRIVE ARE BELONG TO US.

  66. not all PHBs are MS-PHBs by e7 · · Score: 1

    For years, my manager refused to support Microsoft solutions because they weren't standards-based. Unfortunately, we couldn't use Unix either because he didn't want to build or support anything in-house ... as a result, we didn't have anything. Our users were furious, but eventually his teflon wore off :-)

    --
    Corollary to Moore's Law: The IQ of new computer owners is declining.
  67. Re:Use Konqueror - the best pr0n browser by DrSkwid · · Score: 1

    surely you cuold download the Source to mozilla from sourceForge and change it yourself


    .oO0Oo.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  68. Re:Hmm... by DrSkwid · · Score: 1

    you don't need a kick ass mainframe you just need a good distributed OS.

    try plan9 where no user programs run AT ALL on the file server. CPU servers can be added anywhere on the network and used by anybody who's allowed. Yesterday's files are read only on the WORM.

    Unix & Windows both had security ADDED to the model and so kludge the matter.

    Oh, you're a super user, here : read, write or delete anything you like, kill a few processes too while you're at it.

    That's a lot of power for an 8 digit password.
    .oO0Oo.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  69. Re:They should provide more details by hitchhacker · · Score: 3

    I agree you can't "steal" open-source software. But I suspect since sourceforge hosts MANY CVS based projects, that open-source software could be injected with outside code... correct me if I'm wrong, but that seems pretty damn serious.

    cheers,
    metric

  70. The problem with source diffs by btellier · · Score: 1

    Everyone keeps saying "No trojans! Just diff the source! Version control!". People, if the server has been compromised and the cvs server has been compromised, they can modify EVERY version back down to .01 alpha. So you diff it and it comes out clean. Fubar. When you read the source you can easily miss the change between something like:

    memcpy(fu, bar, length - 1);

    to

    memcpy(fu, bar, length);

    And now you have a possible buffer overrun.

    The only way to effectivly diff is if you had copies of the source stored elsewhere.

  71. Re:Care to back that up with facts? [OT] by sracer9 · · Score: 2

    Careful not to feed the trolls too much are they'll get a stomach ache. Or something.....

    --

    No thanks. I don't smoke anymore.
  72. Re:They should provide more details by stilwebm · · Score: 3

    Sourceforge is probably not withholding information because they don't want people to try it again. Whenever there is a complicated compromise, it can take weeks to figure out what has been compromised and how. Generally the priority is to get the system running again, which typically requires a completely fresh start for the operating system. When a system is compromised, it is easy to tell for some thing what probably has been compromised (such as the password files in this case). But most hackers hide their presence from logs as much as possible - even script kiddies do that. Otherwise they would be detected before they got very far, and it would be easier for the victims to figure out how they were compromised.

  73. Re:The OS on sourceforge.net by mdb31 · · Score: 1

    For non-trivial webfarms, the OS running on the servers often has little to do with the TCP/IP packet signature, because of transparent proxies, firewalls and/or load balancers in the path. In this case, SourceForge is most likely running Novell ICS or some other variant on the old "BorderManager" theme. That, or your signature tool is just a bit confused -- not surprising, as different Linux kernel/patch levels have dramatically different signatures.

  74. Re:Windows 2000 secure? Yah, right... by hzoli · · Score: 1
    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.
    Note that attrition.org do have an OS pie chart, which show 59% of the servers are NT and 24% is Linux. Compare to that the cumulative total of around 7300 for NT and 300 for Linux you can conclude that over the August 1999 - April 2001 period NT and Linux were equally likely to be defaced. But you can also see that in March/April 2001 NT is pulling ahead of Linux in the number of defacements.
  75. Security can't be proven by driehuis · · Score: 1
    You can only prove insecurity. That's a basic tenet of the security as well as the cryptography community.

    That said, there is some difference between securing a development server where a gazillion people have shells and need to be able to run arbitrary code, than it is to secure something that, say, only needs to spit out HTML pages.

    --

    Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.

  76. Re:yes, well by carlos_benj · · Score: 1
    Stupid admin is a feature lacking EVERY os. 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.

    I see the settings are also available for spelling and grammar checking.

    --

    --

    As a matter of fact, I am a lawyer. But I play an actor on TV.

  77. Re:They should provide more details by carlos_benj · · Score: 1
    Sourceforge also has a customer base to whom they might want to communicate security issues prior to letting the world know.

    I thought that's what they were doing with the email - alerting their client base to the problem. Unless you mean when it comes time to reveal the nature of the compromise....

    --

    --

    As a matter of fact, I am a lawyer. But I play an actor on TV.

  78. Here's another link by Salsaman · · Score: 2
    Insurers charging more if you use NT

    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.

  79. Re:Care to back that up with facts? by Salsaman · · Score: 3

    How about this one ?

  80. Use Konqueror - the best pr0n browser by marm · · Score: 1

    Konqueror provides almost exactly such a facility, allowing you to disable the Javascript window.open() method whilst otherwise retaining full Javascript functionality. Say bye-bye to annoying popup-windows... for good!

    As I remember, such a feature was proposed for Mozilla some time ago too, but the idea was rejected by the Netscape engineers building Mozilla's Javascript support on the basis that it was a poor idea commercially. Indeed, Netscape's own homepage frequently uses window popups.

    I think from this and other examples (not least Konqueror's other advanced Java, Javascript and cookie management) one could make a strong case that non-commercially-developed Free Software is superior from a user's point of view, as the user dictates to the software what to do rather than a commercial organisation dictating what the software should do. The conflicts of interest that plague other software just aren't there.

    I find it remarkable that such a wonderful yet tiny and easily-implemented feature can be missing from every other major browser. Ask yourself why this is.

  81. Re:Windows 2000 secure? Yah, right... by marm · · Score: 1

    No, I believe you are wrong. If Windows systems are targeted more often, then that in itself is a security problem, is it not? If you had 2 different platforms that were of 'equal security' but one was targeted much more frequently than the other, which would you choose?

    In the security game, it pays to be able to keep your head low and out of trouble, no matter how tough you are.

  82. Re:Windows 2000 secure? Yah, right... by marm · · Score: 1

    Note that attrition.org do have an OS pie chart, which show 59% of the servers are NT and 24% is Linux.

    That's a pie chart not showing overall OS/Webserver marketshare during that time period (Aug 99 - May 01) but rather the share of all the defacements attributable to each OS - so 59% of all the defacements between Aug 99 and May 01 were on NT servers (which here means NT and Windows 2000 combined), and 24% of all the defacements were on Linux servers.

    This only goes to prove the point further.

    Tell me - did you not have any coffee this morning or do you find it difficult to understand graphs and statistics?

  83. Windows 2000 secure? Yah, right... by marm · · 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 (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. 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.

  84. SSH key info on SF by Robbat2 · · Score: 2
    The bit about SSH from the SF email:
    To prevent risk of SSH key data having been compromised, we have also removed any SSH key data you had previously posted to the SourceForge project CVS servers or shell servers, either directly or via the SourceForge website. If you had not posted SSH key data to the SourceForge site or the shell or CVS servers, this paragraph may be disregarded. We request that you review the SSH keys (authorized_keys) and use the 'Edit keys' link on your Account Maintenance page (https://sourceforge.net/account/editsshkeys.php) to post those public keys you are actively using. It should be noted that both SSH1 and SSH2 public key data (identity.pub/authorized_keys/authorized_keys2) may be posted via this interface.

    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."
    --
    ICQ# : 30269588
    "I used to be an idealist, but I got mugged by reality."
  85. Re:yes, well by tracktwo · · Score: 2
    Ya know, its inevitable that someone will bring this up in any slashdot story on either opensource or microsoft. I think we need to have a "law" about it, and I'd like to suggest that it be named after me.

    (C'mon, please? I've never had a law named after me before.)

  86. I hope... by Fat+Lenny · · Score: 1
    the breach didn't expose the valuable intellectual property owned by the hundreds/thousands of Sourceforge projects. Just imagine what would happen if the w4r3z kiddies got their hands on Slashcode -- it would be on Hotline and the IRC warez channels in no time, and *then* what would happen? =)

    --

    --

    --
    fat lenny's gonna lick your brain today.

  87. Re:Change Passwords? by Sheetrock · · Score: 1
    That isn't necessarily so... the passwords could have been plaintext somewhere along the chain. Let's say that a cryptographic hash of the passwords was stored... the computer still needs to retrieve the password from the developer to compare against the hash. If that password wasn't sent via SSL or something similar, it could be sniffed off of the wire from the compromised machine. If it is being sent SSL to an Apache-SSL server, an attacker could compromise the server program or the validation utility that compares the password against the hash.

    The password file is an obvious point of vulnerability, but it isn't the only one.

    ---

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




  88. Re:They should provide more details by aardvarkjoe · · Score: 1

    But I suspect since sourceforge hosts MANY CVS based projects, that open-source software could be injected with outside code... Hm ... maybe this was done by someone who couldn't get people to apply their patches...

    --

    How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
  89. Re:I'm kinda glad. by Gaber · · Score: 2
    "Not releasing the source code would solve many security problems."

    No, not releasing the source would hide many security problems. Probably only temporarily.

    -Gabe

  90. concerns about valinux by tiocsti · · Score: 1

    With sourceforge being hacked, it makes one wonder why companies should trust valinux to do security, if they can not even secure their own network. They have been advertising pretty heavily about their
    security consulting services, and I wonder if there is any reason to believe they can secure their clients' systems any better than they did their own.

  91. Re:Did the root kit use any GPL'd software? by ddent · · Score: 1

    kinda like they sometimes bust drug lords for tax evasion ;)

  92. Re:When it rains it pours. by Lordrashmi · · Score: 2

    My IIS server got hacked! Of course I never tried to secure it cause I had nothing on it....

  93. Re:The OS on sourceforge.net by b0r1s · · Score: 1
    What I find really interesting is the fact that the sourceforge staff appears to have updated apache since the breakin:

    Jan 18th:Apache/1.3.14 PHP/4.0.4pl1 mod_ssl/2.7.1 OpenSSL/0.9.5a

    Mar 29th:Apache/1.3.19 PHP/4.0.4pl1 mod_ssl/2.7.1 OpenSSL/0.9.5a

    I havent seen any apache security issues, maybe it's a convenient time to update...Interesting nonetheless.

    --
    Mooniacs for iOS and Android
  94. Re:The OS on sourceforge.net by YtsaeB · · Score: 1

    I didn't know apache ran on Novell. HTTP/1.1 302 Found Date: Mon, 28 May 2001 22:56:25 GMT Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_ssl/2.8.1 OpenSSL/0.9.6 X-Powered-By: PHP/4.0.4pl1

  95. Re:yes, well by ichimunki · · Score: 1

    Great. Now instead of red-baiting we have RedHat-baiting. How this gets modded up to "5, Insightful," is beyond me.

    --
    I do not have a signature
  96. I know who did it! by sulli · · Score: 2

    It was Shoeboy!

    --

    sulli
    RTFJ.
  97. Re:yes, well by billcopc · · Score: 1

    Insightful because it's the sad yet ironic truth. The supposedly most popular distro is the most pokey of them all. I don't know shit about linux aside from awkwardly setting up Apache and a few mods, yet it's easy to see that RedHat is patchwork-quality when compared to any other distro. Heck, Mandrake's modus operandi is to take RedHat's offering and clean it up, make it nicer. That sure tells alot about RH.

    --
    -Billco, Fnarg.com
  98. Re:They should provide more details by mobiGeek · · Score: 2
    Sourceforge also has a customer base to whom they might want to communicate security issues prior to letting the world know.

    I'm not saying this is the case, I'm just speculating.

    --

    ...Beware the IDEs of Microsoft...

  99. Re:Lets slow down a little, shale we? by Whatanut · · Score: 1

    No, but google would have a license to use the password.

    --

    yvan eht nioj
  100. The OS on sourceforge.net by Rosco+P.+Coltrane · · Score: 2
    Running queso on sourceforge.net reports :

    216.136.171.196:80 * Novell Netware TCP/IP

    Coincidence ?

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:The OS on sourceforge.net by awptic · · Score: 1

      www.netcraft.com is usually pretty accurate for guessing the operating system: The site www.sourceforge.net is running Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_ssl/2.8.1 OpenSSL/0.9.6 on Linux.

    2. Re:The OS on sourceforge.net by $asch · · Score: 2
      In my experience, even nmap's fingerprinting feature is often insufficient. And there are also countermeasures against OS fingerprinting.

      For example, on Linux one can use something like ippersonality 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.

    3. Re:The OS on sourceforge.net by jmcneill · · Score: 1

      Apache does in fact run on Novell Netware...

    4. Re:The OS on sourceforge.net by Nurgster · · Score: 1

      Netcraft can tell you what operating system a server uses, but you do have to pay for that information.

      (They do penty of other stuff besided the web server survey, including security analysis and other online surveys).

      --
      "Faith is the last resort of a desperate man" - Me
    5. Re:The OS on sourceforge.net by lmd · · Score: 1

      Apache has run on Novell since 1.3.14. Too bad netcraft does not tell what version of Linux sourceforge is running.

      --


      Just my $0.04 (adjusted for inflation)
  101. Re:yes, well by atrowe · · Score: 4
    "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."

    I think someone beat you to it.

    --

    -atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.

  102. Re:yes, well by atrowe · · Score: 5
    Typical Slashbot reaction. An open source site gets hacked and your response is "Yeah, well, it happens". If it were an NT/2000 based site you'd all be blathering about how crappy Microsoft is and why everyone should use Linux.

    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.

    --

    -atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.

  103. At the very least... by excesspwr · · Score: 2
    give them credit for doing the right thing. Locking everything down, correcting the problem, and notifying the user. The last step for them to pull this off with absolute dignity is to release how it happened and what to do to fix it.

    They've already done more than what is the usual for most companies.

  104. Re:Care to back that up with facts? by rabtech · · Score: 2

    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.

    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!"

    --
    Natural != (nontoxic || beneficial)
  105. Re:open source myth by rabtech · · Score: 2

    Plus the fact that when you buy Microsoft, you get lots of features that are guaranteed to work together and meshed in a nice, easy to use package. Microsoft offers end-to-end solutions with little overhead -- something that none of the Open Source distros can come close to claiming yet.

    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!"

    --
    Natural != (nontoxic || beneficial)
  106. Did the root kit use any GPL'd software? by JohnTheFisherman · · Score: 3

    If they didn't provide full source for it, we could bust 'em for violating the license ;).

    1. Re:Did the root kit use any GPL'd software? by jsse · · Score: 2

      If they do, RMS will bust them to change name to GNU/Sourceforge.

  107. Re:yes, well by ReverendGraves · · Score: 1
    Stupid admin errors happen both on NT and UNIX - they're not a feature of the OS.

    Damn right they're not. The phrases "End-User Error" and "PEBKAC:Problem Exists Between Keyboard And Chair" both exist for a reason. Computers, properly built, are infallible -- they do exactly what they're told (forgetting manufacturing defects and hardware faults). We the people, the coders, the software developers, are the ones who introduce failings into the machines. OTOH, a computer without software is just a boat anchor.

    --
    MCH/VO S* W- N+++++ PEC+++ D(s++/r) A a+>+++ C* G++(++++) Q+ 666 Y
  108. Re:yes, well by ClosedSource · · Score: 1

    "Clearly opensource developers' intents are noble."

    Give me a break. In what way are open source developers more noble than other developers?

  109. Oh my god! by Beowulf_Boy · · Score: 2

    Somebody might have got some of the sourcecode from the projects!
    Oh, wait.

  110. Re:When it rains it pours. by DankNinja · · Score: 2

    This has nothing to do with open source. Securing a machine where people are shelling is difficult, even with chroot'd environment. It would have happened just as easy on Solaris, Aix, or BSD.

  111. Re:I think the tech downturn is making people cyni by tulare · · Score: 1

    I do think it is important for sourceforge that they make a public post explaining the exploit and how to stop it. My guess is that they will as soon as they figure it out.

    --
    political_news.c: warning: comparison is always true due to limited range of data type
  112. Re:They should provide more details by DaRelliK · · Score: 2

    Sometimes it isn't easy to figure out exactly what did happen after the fact. In addition, they could still be in the proccess of fixing the problem even though they've publicly stated it has been fixed. Remember all those times when your dialup ISP told you it was your telephone company's problem to get you stuck in a loop of call centers to get some time while they fixed a few authenication servers that went down at the ISP. :P

    --
    - darellik
  113. Open Errors. by Fuzzums · · Score: 1

    One of the good things about open source is the possibility to learn from mistakes that others made.
    Let's start Open Security. Document all the security mistakes you know. From programming errors to mistakes in configurations.
    This way everyone can learn from a hack.
    Sooner or later some kiddy wil publish it anyway and sooner or later an other admin will make the same mistake.

    So maybe someone can make a fully documented security-site? :)

    ---

    --
    Privacy is terrorism.
  114. Re:They should provide more details by Zocalo · · Score: 1
    Sourceforge really should provide more details about how security was breached.

    I'm sure they will - once they are sure that the problem is fixed. Let's say they announce a vulnerability in script "foo.cgi"; the upshot of that is going to be lots of haxxors going after one, potentially buggy, target.

    Of course, on the other hand, that is a lot of free debugging too...

    --
    UNIX? They're not even circumcised! Savages!
  115. But it's OPEN! by noz · · Score: 1

    OPEN SOURCE means there's nothing to steal? Unless the modified code *gasp*, but you _do_ have backups... right?

    Even /. backs up! ( :

  116. Re:Lets slow down a little, shale we? by imipak · · Score: 2
    Hear, hear. But when a Microsoft-based site is cracked, even though the patches have been available and publicised on the MS security site, via their email Security Alert service, as well as via Bugtraq and NTBugtraq, isn't that due to bad sysadmin as well? You could certainly make the case that a much higher percentage of Microsoft admins are *likely* to be clueless / lazy about applying patches diligently... although how Linux admins of reasonably functional workstations stay sane, I can't imagine. Unless you assume that anyone on your LAN is trusted (a bad mistake IMHO)... I've frankly given up on patching my (Mandrake) box, there's waay to much software to keep track of, and life's too short to spend hours a day reading Bugtraq, downloading and applying patches when yet another buffer overflow is found in Pine (or whatever)...

    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"

  117. Re:Lets slow down a little, shale we? by imipak · · Score: 2
    Sure, apt (sounds) much better than RPM (and InstallShield ;)... but that wasn't really my point.

    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"

  118. Re:open source myth by IanA · · Score: 1

    PHBs aren't interested in why not to use Microsoft. That is why they're PHBs. They look for reasons not to use Linux, and that perceived myth is one of them. So if Microsoft has security problems or not isn't an issue since PHBs _want_ to stay with it and can overlook the shortcomings.

  119. Re:You must be joking by chrylis · · Score: 1

    And what security flaws can you cite in Linux? Not Apache, not pine. Actual security flaws in Linux itself, please.

    Kernels in and of themselves, as they have no way of communicating with the outside world, are completely secure--they don't become insecure until you at least add drivers.

  120. Re:Lets slow down a little, shale we? by Husaria · · Score: 1

    And if it was posted via Google, would the system password be owned by Google?

  121. Hmm... by Scoria · · Score: 2

    Seems like SourceForge is making no mention of it on their front page.

    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, 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!

    --
    Do you like German cars?
    1. Re:Hmm... by towatatalko · · Score: 1

      "No operating system, not even our beloved Linux, is totally secure" -- in general that sounds right, however, security goes beyond OS running on some box, in other words it's not just software. If physical enviroment is compromised by someone attaching a listeneing device to the network even the most secure software fails. In that regard mainframe base network is by far more secure than dostributed server based network. In addition, the philosophy that dogmatically applies multiple servers manged by several people increses the odds even more against distributed networks. If your network grows beyond 30-40 servers it's time to think mainframe. On most mainframes you can't run executable program unless it is authorised by the OS. That means no virus can damage the system and usualy only one/two people manage one box, etc. Therefore, in my view, network (in)security is not so much software or OS problem, but rather dogmatic overreliance of some network managers on distributed network ideas and models, which creates security holes that can be exploited at more than one entry point.

      --

      IP was invented for the sake of lawsuits.
  122. Lets slow down a little, shale we? by Zenin · · Score: 3

    When we yell about this site or that site getting cracked while using MS products, it is typically tied with a report explicitly stating that it was, infact, a MS product that had the security hole.

    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.

    --
    My /. uid is better then your /. uid
  123. Psss! Hey! You! by Kragg · · Score: 1
    Wanna buy some opensource? Huh? Going very cheap.

    You see, I only ordered one file, but they sent me two, so i'm selling this one on for next to nothing...

    Go on, man, this stuff's golddust you know. You Can't get this just anywhere...


    "God is dead." - Nietszche

    --
    If you can't see this, click here to enable sigs.
  124. When it rains it pours. by glrotate · · Score: 1

    Hopefully OpenSource's luck will change soon. This is starting to get depressing.

  125. Re:You must be joking by Ayende+Rahien · · Score: 1

    http://www.linuxsecurity.com/advisories/redhat_adv isory-1151.html

    http://www.linuxsecurity.com/advisories/other_ad vi sory-1306.html

    BTW, I would assume that Win2K kernel is much more secure than the Linux kernel. Reason being that Win2K is a semi-mirco-kernel, while Linux is a monolitic kernel.
    Micro kernel means that the kernel is as small as possible, and everything is loaded via "modules" (not exactly, but close enough).

    Linux, OTOH, incorporate much into the kernel.

    For example, take TCP/IP. If you want to remove that from the kernel, you need to rebuild it (so with Linux, at least, you do have a way of communicating with the outside world via kernel alone). On Win2K, you don't need to rebuild the kernel in order to remove TCP/IP.

    --

    --
    Two witches watched two watches.
    Which witch watched which watch?
  126. Re:You must be joking by Ayende+Rahien · · Score: 1

    Haven't built one.
    Win2K kernel has a totally different design than Linux has. You can't adequately compare it.

    --

    --
    Two witches watched two watches.
    Which witch watched which watch?
  127. They been trying for a while. by AX.25 · · Score: 1

    Someone on the local lug list reported that someone hit their userid and it send the email with link to reset their password. At the same time they reported a DOS against their mail server causing mail to backup on their secondary. This was in April.

    --
    What is pirate software? Software for inventory of stolen treasure?
  128. Re:why don't these morons by multicsfan · · Score: 1

    They can't, it very easy to destroy and very hard to create. By destroying things, they show thelr lack of skill and inability to do useful things.

  129. I'm kinda glad. by Burgundy+Advocate · · Score: 1
    This finally gives people a chance to see the open-source security model in action.

    I know that I'm preaching to the choir here, but when an exploit like this happens, the developers are quick to patch the program that caused the security hole. Just look at Sendmail!

    However, the original problem is that the source is open. Since the hackers can look through the code, they can find all the exploits. Sometimes I wonder if the GNU/Linux community wouldn't be better off taking a cue from professional developers and just releasing binaries. Not releasing the source code would solve many security problems.

    --

    --
    Dragging people kicking and screaming into reality since 1996.
  130. Re:yes, well by jimsxe · · Score: 1

    Also it is a commercial product (Windows) So I think a product that one has to pay for and touts itself as a "solution" Better be secure. And of course it sucks If something is free you shouldnt bitch about it and conversly if I pay for something and I have a loss due to that crappy product then that products manufacturer should be held responsible

    --
    This is not a Sig.
  131. Freedom=Hacks by SiMac · · Score: 1

    Well, the SourgeForge hack was probably a result of the amount of freedom SourceForge gives its users. I don't know of any free web host which gives its users a shell account, probably partially because it's too much of a security risk (well, that is except for me, but I only give webspace to trusted friends). With the amount of freedom SourceForge gave its users, this was bound to happen. This is not a suggestion that SourceForge reverse its policies. Instead, I believe that this is a testament to the honesty of open source developers (and the work of SourceForge) that this doesn't happen too often.

    --

  132. yes, well by spacefem · · Score: 2

    Big web sites have these from time to time, shake things up, keep everybody on their toes, give us all something to think about. It's too bad it happens to ones on our side, of course. Guess something besides their source was left open, huh?

    1. Re:yes, well by chuzwuzza · · Score: 1

      Why cant you people just have a discussion? why do you always have to bring karma into in? can't you just dissagree with someone for teh sake of their argument, and not for how many points they get? who cares really? are mod points going to make you a better person? no.

    2. Re:yes, well by potatoallan · · Score: 1
      This post is FUD or troll Where did you see this typical slashdot reaction?

      The only reason to blather MS for their security is the backdoors of it. Because as you say no piece of software is 100% secure. Just MS has the addition of backdoors.

      The moderation of this post proves, umm, something...

      fp!

  133. No, they should not provide more details by slashdot_commentator · · 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.

    --
    There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
  134. That's open source security for ya... by kypper · · Score: 2
    Heh, just kidding.
    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.

  135. Re:Inevitable... by chuzwuzza · · Score: 1

    yeah, i agree. i'm in australia and everytime i get on the internet in the evening's, which is peak time here, they're always doing nightly database maintanence! very annoying

  136. SourceForge Infected With HooverWorm by christoofar · · Score: 1

    Perhaps SourceForce is victim to the same worm that was trying to plug up Linux security holes by traversing source and identifying nasty undocumented source and sending remindergrams to authors to document their work?

  137. Re:Plaintext passwords by Snootch · · Score: 1

    Of course they store their passwords in plaintext, and for the same reason - how else can they mail you your password?

    43rd Law of Computing:

  138. GIVE OUT THE IP by shadash · · Score: 1

    The sourceforge admins should look through the logs and find out at what point, by who, and how their servers were compromised. Post all the information publicly including IP's and let the hacker become the hacke. Seriously, I couldn't think of a worse group of people to piss off than programmers that have created most of the internet. Plus like mose Linux users hacking skills are second nature. I've just been looking for an actual reason to use them.

    1. Re:GIVE OUT THE IP by shadash · · Score: 1

      Yea I know. But if they didn't cover their tracks... Time to die...

    2. Re:GIVE OUT THE IP by gnurd · · Score: 1

      oh c'mon. if your hacking skillz r 50 '1337 you whould know that if SF did that they would just be pointing tons of angry people at some poor sysadmin at some public library in Podunk, USA who had been 0wn3d for months without knowing it.
      ---

      --
      "i was saying gnu-rd"
  139. You are correct by ColGraff · · Score: 2

    I was unable to find any kernal flaws in Win2k. However, the software bundled with Win2k, including WMP, is full of security flaws. I stand corrected.

    --
    I'm the stranger...posting to /.
  140. Not necessarily by ColGraff · · Score: 2

    The crackers might have used an alternative such as IP spoofing to gain access.

    --
    I'm the stranger...posting to /.
  141. They should provide more details by ColGraff · · Score: 5

    Sourceforge really should provide more details about how security was breached. They probably are reasoning that if they give details, other people will do the same thing. However, anyone who's interested in this sort of nonsense probably already knows.

    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.

    --
    I'm the stranger...posting to /.
    1. Re:They should provide more details by discogravy · · Score: 1

      That's okay, refunds are on the way...oh wait...

      it could have been microsoft, trying to get the source to linux, for their own nefarious reasons.

      -d.
      --
      "If you're really evil, let's see you EAT THIS KITTEN!"

  142. sourceforge... by Goncalo+Gomes · · Score: 1

    its very sad to see that great projects such as sourceforge are compromised by scriptkidiots (?), however it is very hard to maintain machines secure when we provide local access, the best they could do from now on, is removing SSH access to the user accounts, and keep the software

    up-to-date.

    good luck.

    --
    "After twelve years of therapy my psychiatrist said something that brought tears to my eyes. He said, 'No hablo ingl