Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Open Source Security Linux

Linux Foundation, Linux.com Sites Down To Fix Security Breach 101

Posted by timothy
from the bringing-back-spanking-might-help dept.
An anonymous reader writes "All Linux Foundation sites seem to be down due to a security breach, which occured on 8 sep. (according to a notice displayed on the site)." From the email I received this morning, sent to all Linux.com and LinuxFoundation.org users: "On September 8, 2011, we discovered a security breach that may have compromised your username, password, email address and other information you have given to us. We believe this breach was connected to the intrusion on kernel.org. As with any intrusion and as a matter of caution, you should consider the passwords and SSH keys that you have used on these sites compromised. ... We have taken all Linux Foundation servers offline to do complete re-installs. Linux Foundation services will be put back up as they become available. We are working around the clock to expedite this process and are working with authorities in the United States and in Europe to assist with the investigation."
This discussion has been archived. No new comments can be posted.

Linux Foundation, Linux.com Sites Down To Fix Security Breach

Comments Filter:
  • by betterunixthanunix (980855) on Sunday September 11, 2011 @09:32AM (#37368026)
    Uh...isn't the point of using public keys that you do not have to keep them secret to remain secure? If people uploaded their public keys to the compromised systems...how is that a problem?
    • by smash (1351)
      Ahh, but if you were a dumb ass and placed your private key for linux.org on say, kernel.org (to log into one from the other), then if kernel.org got hacked, your key is gone.
      • by kestasjk (933987) *
        Why would you do that?.. Usually people sacrifice security for convenience, but that is less convenient..
        • by smash (1351)
          Because you're a dumbass.
        • Why would you do that?

          Maybe in case you'd need to scp large files from linux.org to kernel.org and vice-versa, without having to first download them to your home machine, and then upload them to the target (slow, if you've got asymetric DSL)

          Of course, dumb users not aware of security implications is also a possible explanation (less likely though, as dumb users would probably not be aware of ssh authorized_keys in the first place...).

          In both cases, it is smart of the Linux Foundation to warn their users of this potential issue

          • That being said, it's important to use a different private key on each machine where you might ssh from...

            However, in case of a compromise, you'd still need to remove trust in the private key of the impacted machine (so if kernel.org got hacked, you need to remove your old kernel.org's public key from your ~/.ssh/authorized_keys on linux.org)

            Also, if the hacker got kernel.org's /etc/ssh/ssh_host_rsa_key, then he could theoretically later on mount an MITM attack against kernel.org... so the kernel.org admi

            • That being said, it's important to use a different private key on each machine where you might ssh from...

              Hell yes, and for key management sanity it is good to use a clear comment on keys so you know what they are for.

              However, in case of a compromise, you'd still need to remove trust in the private key of the impacted machine (so if kernel.org got hacked, you need to remove your old kernel.org's public key from your ~/.ssh/authorized_keys on linux.org)

              You also have to rebuild authorized_keys to check that no new or modified keys have been added. That would allow the hackers right back in at some future time. I keep a copy and cksum of authorized keys for every machine where I use keys, just so I can check. Yes, I'm paranoid.

              Also, if the hacker got kernel.org's /etc/ssh/ssh_host_rsa_key, then he could theoretically later on mount an MITM attack against kernel.org... so the kernel.org admins better change that one as well (while publishing the new key's fingerprint on an SSL server).

              I don't know if that's the case, but they could certainly set up a fake server if they have your public key and the server

          • by rastos1 (601318)

            Maybe in case you'd need to scp large files from linux.org to kernel.org and vice-versa, without having to first download them to your home machine, and then upload them to the target (slow, if you've got asymetric DSL)

            That's why there is -A option for ssh.

      • by Anonymous Coward

        Dumbass is right. That's why OpenSSH has agents (and the ssh agent does NOT expose your key, it does all crypto and returns just the result). SSH private keys should NEVER leave your own box. You don't reuse openssh keys, either. It is one private key pair per host.

        That would not have saved HPA's keys since his laptop was the entrypoint of the kernel.org breach, but if some people were not lazy assholes, there wouldn't be any private keys on kernel.org, except for some automated tasks (which have to be

        • Why shouldn't I re-use my ssh keys? I'm pretty clear on all your other points so I assume that you've got a good reason for this. What is it?

          I feel that I may have mis-understood the proper use of SSH keys and would really like to know the attack vector here.

          • by ttong (2459466)

            I once had a co-worker who was as stupid to do that, so I immediately blacklisted his key on every machine on the corporate network and told him to generate a new one and keep the private part to himself. I sincerely hope any sane IT dept. will do the same in that event.

            It's almost as stupid as emailing the root password in the clear for the new dedicated server you've ordered. Mail me the host key fingerprint, I'll mail you my public key. How hard can it be?

            • The statement that I was in disagreement with was "You don't reuse openssh keys, either. It is one private key pair per host."

              Bullshit unless there is something that I'm missing. Keep one private key / public key pair and use the public key on all things you want to access. Keep the private key private (read: in a private place, encrypted. As is traditional.)

              Is there some problem with re-using your public key on several servers? I think not.

              • by ttong (2459466)

                Yes, you are correct. Nothing wrong with the same public key on 100+ servers.

                Though I can also relate to having a separate key pair for internal servers and another for customer servers. That way, when you use an agent and unlock a key you don't unlock every server you ever have to manage anywhere. Especially when you have a multitude (say, 5 at max) of key pairs for that purpose.

    • by maswan (106561)

      It is an unfortunately common case that people copy/create private ssh keys on servers to login (or scp) from those to another remote host. These keys are of course compromised.

      • It is an unfortunately common case that people copy/create private ssh keys on servers to login (or scp) from those to another remote host. These keys are of course compromised.

        There is no requirement to do that. You can just create a tunnel through the first server to the second (ssh -L). Then you connect to the tunnel port on localhost, and you never had to give away your private key. You're even safe if the server in the middle gets compromised.

    • by smash (1351)

      Also - don't forget, if someone has your public key (and has compromised the server's key), they can impersonate the remote end and go for a man in the middle attack.

  • by LinuxScribe (158687) on Sunday September 11, 2011 @09:36AM (#37368060)

    A few more details of the breach, including the content of the message from the Linux Foundation, can be found on ITWorld [itworld.com].

    LinuxScribe

    • The information I really want to see is a statement clarifying this as either technical as in a failure of the security software somewhere, or administrative, as in someone left something open through error or poor security design choices.

      It's important to know if this is a bug which is on all Linux systems, or someone made a human error.

  • First Kernel.org and now this? Has someone got it in for FLOSS at the moment?
    • by Nerdfest (867930)
      No, someone would like unrestricted, undetected access to make 'modifications' to the most popular server OS.
      • Those are just pubic facing servers, not the dev team's workflow boxes. However, even if they were their source code management tool, git, exposes every change made by anyone for all time. It is simply that nature of git. Check it out if you want details. Even if they didn't use git the maintainers and anyone with clean copies (per-breach) can simply run a diff on the source code vs any new "untrusted" copy they may see.

        Since they've made the breach public and the aforementioned steps to detect any modifica

  • Total Irony (Score:2, Offtopic)

    by adosch (1397357)
    I am not sure what is gained by breaking into, compromising and exploiting a foundation like The Linux Foundation when the perps were more than likely using a Linux driven OS and tools to do what they did. Seems like some need a re-education in not harming the hand that builds your house...
    • by phoric (833867)
      Follow the money. Who stands to gain from creating fear, uncertainty, and doubt surrounding Linux and it's related organizations?
      • by Anonymous Coward

        Follow the money. Who stands to gain from creating fear, uncertainty, and doubt surrounding Linux and it's related organizations?

        Exactly! The folks at BeOS!!!!

        • by PNutts (199112)

          Follow the money. Who stands to gain from creating fear, uncertainty, and doubt surrounding Linux and it's related organizations?

          Exactly! The folks at BeOS!!!!

          BeOtcheS. BeOtcheS love FUD.

  • by Anonymous Coward
    Having said that, reasonable people may conclude that the occasional security breach is an acceptable price to pay to avoid dealing with Theo. :-)
  • Not like when a CA gets its webserver compromised, has a quick self audit and then declares everything is OK, really, honest....

    Assume everything is compromised unless you can prove otherwise and get the staff in on overtime to reinstall from scratch.
  • Thats unpossible.
  • How could an attacker getting hold of the public key "compromise" anything? It doesn't contain any personal information, and -- barring an earth-shattering breakthrough in cryptanalysis of RSA (or DSA, if you chose a DSA key pair) -- it can't be used to gain access to anything, not even the system it was stolen from.

    That's the whole point of using asymmetric cryptography for authentication!

    • by smash (1351)
      You're assuming only public keys were compromised. If they had private keys enabling login to other hosts stored on said systems (yes, retarded, but...) then those keys are compromised.
      • by swillden (191260)

        You're assuming only public keys were compromised. If they had private keys enabling login to other hosts stored on said systems (yes, retarded, but...) then those keys are compromised.

        A little more than retarded... in order for someone to do that they'd have to have never heard of ssh-agent.

        • ssh-agent leaves an active and unlocked ssh-key available on the relevant server. Many of my colleagues refuse to run their ssh-agent as part of their own persoanl host's working environment, and prefer to host them on their most used server, despite my warnings. Others find ssh-agent burdensome and simply use passphrase-free keys, and there is not yet any graceful way to prevent that except to audit for them on the client hosts, which is awkward and intrusive.

  • "you should consider the passwords and SSH keys that you have used on these sites compromised."

    How the heck can ssh keys compromised by this breakin? Doesn't the site just have access to the developer's public key? With a sufficiently large ssh key (say 1k or 2k) how is anyone going to derive the ssh private key from the public key? The fact that if is effectively impossible is supposed to be the whole point of public key encryption.

Physician: One upon whom we set our hopes when ill and our dogs when well. -- Ambrose Bierce

Working...