Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Linux

Kernel.org Compromised 312

First time accepted submitter JoeF writes "There is a note posted on the main kernel.org page indicating that kernel.org was compromised earlier this month: 'Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure.' The note goes on to say that it is unlikely to have affected the source code repositories, due to the nature of git."
This discussion has been archived. No new comments can be posted.

Kernel.org Compromised

Comments Filter:
  • Wishful thinking (Score:2, Insightful)

    by Mensa Babe ( 675349 ) *
    "[I]t is unlikely to have affected the source code repositories, due to the nature of git" [emphasis added] Yeah, because no one has ever downloaded the kernel any other way than by making a local fork of the git repository. No one has ever used the http, ftp and rsync links on the kernel.org website, or clicked the "Latest Stable Kernel" icon on that very website, right? Also remember that the mirrors [kernel.org] don't mirror the git repositories but the http/ftp archives from kernel.org servers, the very same server
    • by Anonymous Coward on Wednesday August 31, 2011 @07:08PM (#37270566)

      And seriously, why else would you hack kernel.org?

    • by Amouth ( 879122 )

      but if the repos are still good - then it should be easy to trace any changes/modifications to the other distribution channels - and update/inform the people who use them

      • by drolli ( 522659 )

        Ahem. i did not leave my email there to notify me the last time i downloaded the tarball

        • by skids ( 119237 )

          Ahem. i did not leave my email there to notify me the last time i downloaded the tarball

          ...why anonymous ftp and leaving your email address in the password field can be a good thing. Not that anyone does that anymore.

          The main point is, it won't take a line by line audit to look for malicious code, rather just working with the crypto to verify a chain of trust.

    • Re: (Score:3, Insightful)

      by X0563511 ( 793323 )

      Are you stupid?

      The files are in a git repository. That's what matters, not what you wrap around it to provide for requests. Anyone who happened to have a local git copy will notice VERY QUICKLY what changed when they try to commit... and I'd venture to say that nearly all of the kernel developers Who Matter use git for their development workflow.

      • by bill_mcgonigle ( 4333 ) * on Wednesday August 31, 2011 @07:24PM (#37270660) Homepage Journal

        The files are in a git repository. That's what matters, not what you wrap around it to provide for requests.

        So http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.4.tar.bz2 [kernel.org] gets pulled dynamically from git?

        the kernel developers Who Matter

        Are you saying users don't?

        • by Dunbal ( 464142 ) *
          Users generally use code, they don't write it. They matter because they are who the code is written for, however they don't matter when it comes to modifying the code. /feed
        • Imagine the following scenario:
          You Download source code from a tarball at kernel.org. You develop against that. You commit to git. You change only 3 files and git tells you there are 20 files changed. This is when you realize that somehow, the tarball differs in 17 files from the git repository.

          How many developers actually develop against a freshly downloaded tarball off ftp/http kernel.org mirror, in stead of a checkout/sync from the clean git branch? Because only the ones that do, and also have commit
      • by drolli ( 522659 )

        Actually, i think you are wrong. As far as i understand the repository is not checked during a commit. Edit directly in the repository and your modification will only be uncovered by git-fsck AFAIU.

    • by Manfre ( 631065 ) on Wednesday August 31, 2011 @07:50PM (#37270866) Homepage Journal

      If the attackers were worth their salt, after gaining access they would drop in their own custom replacements for patch, make and gcc. For such a large code base, it is not easy to tell if the code going in is yielding the expected instructions.

      • Re:Wishful thinking (Score:5, Informative)

        by nabsltd ( 1313397 ) on Wednesday August 31, 2011 @08:04PM (#37270972)

        If the attackers were worth their salt, after gaining access they would drop in their own custom replacements for patch, make and gcc.

        Since patch, make, and gcc are all GNU tools and not part of the Linux kernel, the only harm would be to the single copy on the kernel.org machine. If that machine isn't part of the build process (i.e., if it was merely a file repository), then nothing would be compromised.

        It would also be pretty easy to see because builds from other machines wouldn't match.

        • It would also be pretty easy to see because builds from other machines wouldn't match.

          Would it? I'm wondering because in all my life, downloading and compiling stuff, I've never compared a binary with one compiled on a different machine to see if it matched. Maybe someone would, which is why I am asking. Are there people who commonly do that? Why?

        • Since patch, make, and gcc are all GNU tools and not part of the Linux kernel

          It's not exactly hard to make a kernel that would specifically check for loading of those processes, and patch them up on the fly to make them behave as it needs.

    • Re:Wishful thinking (Score:5, Interesting)

      by bzipitidoo ( 647217 ) <bzipitidoo@yahoo.com> on Wednesday August 31, 2011 @07:56PM (#37270918) Journal

      You know what? Linux users will go right on using plain Linux. Not SE Linux, not OpenBSD, and certainly not Windows. We're not even going to change our root passwords. Why? Because this security breach is not that big a deal.

      Yes, it is embarrassing for kernel.org, but the damage is not that great. Sure, we'd all like to prevent security breaches from ever happening in the first place, but I have always thought detection and recovery is more important than prevention. Kernel.org has that covered in spades. Keep backups. Keep many backups. Keep them in many different locations. A distributed source code revision control system such as git does that automatically. Whoever did this wasn't too smart if they were seriously trying to inject a backdoor into the Linux kernel. Now they've blown their cover. They can't have seriously expected the code modifications they tried to go unnoticed for long, unless they have no idea how large projects handle source code. So either they were dumb, or all they were trying to do was embarrass Linux.

      • You know what? Linux users will go right on using plain Linux. Not SE Linux, not OpenBSD, and certainly not Windows.

        Maybe the Ubuntu users. Myself, I like a kernel enhanced [wikipedia.org] with capabilities [wikipedia.org]. It saved my butt once from the bugs the mighty kernel developers introduce ever so often in the kernel, with their "release early, release often" philosophy (we see now where that leads with this incident).

    • You don't git it (Score:3, Informative)

      by Anonymous Coward

      Also remember that the mirrors don't mirror the git repositories but the http/ftp archives from kernel.org servers, the very same servers that has been compromised. The kernel.org home page encourages visitors to use those mirrors so it is not unreasonable to assume that some people do in fact use them.

      Not need to panic. Yet. Most users don't download their kernels from kernel.org. This is a fact. Most users download via the package repositories of their favorite Linux distro, say Ubuntu or Arch. And the ke

  • Oops (Score:5, Insightful)

    by drolli ( 522659 ) on Wednesday August 31, 2011 @07:05PM (#37270534) Journal

    This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.

    • Re:Oops (Score:5, Insightful)

      by jrbrtsn ( 103896 ) on Wednesday August 31, 2011 @07:42PM (#37270812)

      If the same thing happened to Microsoft, Microsoft wouldn't let anybody know.

    • Re:Oops (Score:5, Funny)

      by MaxBooger ( 1877454 ) on Wednesday August 31, 2011 @07:52PM (#37270880)

      This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.

      Nah. They wouldn't bash them. cmd them, maybe. But not bash them.

  • Huh? (Score:2, Funny)

    But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.

    A trojan startup file was added to the system start up scripts

    But Linux has no viruses/trojans/malware, right?

    BTW - if you can't take this as the light jabbing it's supposed to be without wanting to rip my spine out, turn the computer off and take a break. :)

    • I suggest you look up the definitions of these words before you start using them.

    • But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.

      Hurr durr, patching the source code of software with malicious code means the software has always been inherently insecure....

    • by Dunbal ( 464142 ) *
      Now just imagine what someone somewhere is doing to all the Macs and iOS stuff.
  • Who's going to compromise the Linux kernel servers, and leave the linux kernel alone?

    • I suppose that depends on whether compromising the Kernel source on kernel.org without detection is seen as possible. If it isn't (and kernel.org seem quite confident that git would protect against it) then the 448 users of Kernel.org may be a better target.

      Considering they presumably include people from the major distros using the kernel.org compromise as a starting point to gain access into other organisations might be more valuable than a risky direct attempt on the kernel itself.
  • The kernel.org sources live on OS X Lion boxes - authentication is handled through LDAP.

  • Yes, diff against any of the thosand mirrors is going to be reallly really difficult to run and there is going to be rootkits in my linuxes.


    s/police/hackers/ And i quote:
    JeffK: "Oh noes, teh police! HIDE TEH LUNIX!!!11"
  • by seifried ( 12921 ) on Wednesday August 31, 2011 @11:45PM (#37272126) Homepage

    Here's a hint: the developers use git, which identifies all commits by their SHA1 value, so changing the contents of a commit will cause the SHA1 sum to mismatch which would cause git to howl and complain. So they then build a tarball and upload it to the server. They also upload signatures:

    patch-3.0.4.bz2 29-Aug-2011 20:57 94K
    patch-3.0.4.bz2.sign 29-Aug-2011 20:57 249
    patch-3.0.4.gz 29-Aug-2011 20:57 107K
    patch-3.0.4.gz.sign 29-Aug-2011 20:57 249
    patch-3.0.4.sign 29-Aug-2011 20:57 249

    So unless they manage to compromise the Kernel signing key any changes would be immediately noticeable (assuming people check the signatures, which they do).

    • Re: (Score:3, Interesting)

      by Octoploid ( 855458 )
      The private signing key + passphrase are normally present on hera. So all tarball signatures could be compromised.

It is not best to swap horses while crossing the river. -- Abraham Lincoln

Working...