Slashdot Mirror


Debian Locks Out Developers

daria42 wrote in with an update to an earlier story about a Debian server that was compromised. He explains: "The Debian GNU/Linux project has discovered a compromised developer account was used to gain access to a server compromised this week. A local kernel vulnerability was then used to gain root access. Due to this, a number of developers with weak passwords have been locked out of their system accounts." To be fair, they'll most likely be let in once everything's back to normal. Of course, they'll probably need to set safer passwords too.

17 of 331 comments (clear)

  1. kernel exploited... by scum-e-bag · · Score: 4, Informative
    Schulze said the particular Linux vulnerability only
        exists in kernel versions:

    • 2.6.13 up to versions before 2.6.17.4
    • 2.6.16 up to versions before 2.6.16.24


        Schulze advised admins to upgrade their software if they were
        using these versions but said the current stable version of
        Debian was not affected as it run kernel 2.6.8.


    I guess this means that there are a lot of ubuntu users out there who are vunerable right now... how long for the patch?

    Also, the article seems to be a little out. Shouldn't it be just 2.6.12 -> 2.6.17.4 as this includes 2.6.16 -> 2.6.16.24
    --
    Does it go on forever?
    1. Re:kernel exploited... by kevlarman · · Score: 2, Informative

      dapper drake uses the http://packages.ubuntu.com/dapper/base/linux-image -3862.6.15.xx kernel so it wouldn't be affected

      --
      A mouse is a device used to point to the xterm you want to type in
    2. Re:kernel exploited... by scum-e-bag · · Score: 5, Informative

      According to the ubuntu-security-announce lists, the current up to date kernel version is 2.6.15-26.44 This was released 3 days ago, before the debian server compromise was announced. According to the zdnet report, this version falls within the exploitable.

      I made a mistake in my initial post, slip of finger, 2.6.13* not 2.6.12*

      --
      Does it go on forever?
    3. Re:kernel exploited... by andersa · · Score: 3, Informative

      Since the 2.6.16 kernels are still being maintained with regard to bugfixes, the statement is valid. The vulnerability was fixed in maintainance release 2.6.16.24 and versions of 2.6.16 from then on forward are ok.

  2. Re:So? by Anonymous Coward · · Score: 1, Informative

    Have you thought this through? The point of regularly changing passwords is so that if a blackhat gets a password then it will only work for a limited time. If a blackhat can find the password "KmcJxusUc822" that was stored on a old broken backup harddrive found in a flee market, it won't be of any use to him if the password is changed monthly, *unless* the user uses incremental passwords. If the backup is one year old then the blackhat only has to guess a password around "KmcJxusUc834".

  3. Re:Passwords by Anonymous Coward · · Score: 3, Informative

    By running cracking tools against them, of course.

  4. Re:ssh2 keys? by mibus · · Score: 2, Informative

    It's a public-key encryption system.

    You generate a public/private key pair on your computer. You send the public key to the admin of the server, who installs it for your account on that server. When you try to connect, instead of passing along a password, you pass along a "login" message digitally signed/encrypted using your private key. The server can use your public key to verify that it's really you.

    It's like PGP/GnuPG, but for user accounts instead of people.

  5. Re:Passwords by ozbird · · Score: 4, Informative

    John the Ripper most likely. Great tool - recovered the root password for a SGI box a friend bought on eBay in less than a second (your password may vary.)

  6. Re:libpam-cracklib by ArbitraryConstant · · Score: 2, Informative

    The search space for a 1024-bit private key isn't as big as for a symetric key of that size. It's still better than a password though, and there's nothing restricting it to 1024 bits.

    --
    I rarely criticize things I don't care about.
  7. Re:Ah. balance by DMUTPeregrine · · Score: 2, Informative

    I use Kee pass for storing the random passwords. The database is secure enough, and I only have to remember one password (well, I keep a few fast to type insecure passwords for use in things I don't care about, like one-time-use stuff.)
    N64ÞEm¢f:]&ÆqfNP8Q_- is a nice password, and not THAT hard to memorize... N64 ALT+0222 capital-E m ALT+5787 f:]& ALT+5778 qf capital-N capital-P 8 capital-Q _-
    It would probably take me about half an hour to memorize it, a few days of use to get perfectly consistent. Writing it down until then works, then destroy the paper it was written down on.
    After that, all my passwords can be random junk and I'll be able to memorize them.

    Also, keepass allows attatching files. One could have many password databases, each embedded into another. wheeeeeee

    --
    Not a sentence!
  8. Cracking "weak" passwords is trivially easy by xactoguy · · Score: 2, Informative

    Cracking passwords when you have access to the non-reversible hashed versions of the passwords (aka "/etc/shadow") can be trivially easy on modern hardware, when using a tool such as John the Ripper, or, if you have a lot of spare harddrive space (and RAM), RainbowCrack. If this box was using md5 hashes (most likely), JTR on modern hardware can easily crack 8,000+ passwords a second, which, when combined with advanced password guessing techniques, will most likely find weak passwords within an hour or two.

    --


    And so we go, on with our lives
    We know the truth, but prefer lies
    Lies are simple, simple is bliss
  9. Re:Ah. balance by zerblat · · Score: 2, Informative
    Two separate passwords are always better than just one
    Sure, having two 8 character passwords is more secure than just one 8 character password, but it's equivalent to having one 16 character password.
    --
    Please alter my pants as fashion dictates.
  10. Accounts with bad passwords locked, not all by dondelelcaro · · Score: 5, Informative

    The story title is a bit misleading; only accounts with bad passwords or those who (for $DEITY knows what reason) appeared to have private keys on gluck were locked out. Everyone who has sane passwords and/or only uses ssh keys to log into their accounts still have access.

    Of course, anyone who could actually log in already knows this because they've read d-d-a (or have already logged in.) In any event, rather troubling that the PRCTL bug managed to find its way into the kernel, but good that the intrusion was caught relatively quickly and neutralized.

    --
    http://www.donarmstrong.com
  11. Re:Ah. balance by BecomingLumberg · · Score: 4, Informative

    Well, the parumutaions change depending on whether or not the program displays that you are correct with the first password. Cracking a 16 digit password would square the time it took to crack, where two eight digit passwords separatly would simply double it.

    --
    If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be.-TJ
  12. Re:Ah. balance by aymanh · · Score: 4, Informative
    Talking about openssh's security, here's a vital patch:
    -PermitRootLogin yes
    +PermitRootLogin no

    A couple more:

    Protocol 2
    PermitEmptyPasswords no
    LoginGraceTime 2m
    MaxAuthTries 6

    And it's always a good idea to restrict SSH access to trusted IP addresses in /etc/hosts.allow.
    --
    python>>> q="'";s='q="%c";s=%c%s%c;print s%%(q,q,s,q)';print s%(q,q,s,q)
  13. Re:Ah. balance by ericlondaits · · Score: 2, Informative

    No, actually the mistake was all mine.
    I hereby declare to be a complete tool, and my only defense is the fact that the amount of caffeine in my blood was not enough to compensate my sleepy state.

    A 8 character password has C^8 possible combinations (where C is the number of available characters). A 16 character password has C^16 possible combinations... and C^16 == (C^8)^2.
    So doubling the length squares the search space, and you were correct.

    --
    As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
  14. Re:howto: strong passwords by Just+Some+Guy · · Score: 2, Informative
    If you are in need of a strong password, use the following recipe:

    A password generating algorithm that doesn't use acronyms like "AES", "PRNG", etc. doesn't meet the definition of "strong". The problem with your method is that it's extremely vulnerable to frequency analysis. For example, the results will almost never contain the substrings "zq", "xg", "uz". That doesn't necessarily make your passwords week, but they definitely fall short of being cryptographically random.

    A better approach is to use something like "pwgen -s" to create one really good password. Then, use that as the encryption password on a database storing all your other computer-generated passwords. I couldn't give you my online banking password if you put a gun to my head since I only saw it once: when I was copying-and-pasting the output of pwgen into my webbrowser.

    --
    Dewey, what part of this looks like authorities should be involved?