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.

13 of 331 comments (clear)

  1. Ah. balance by Kid+Zero · · Score: 5, Insightful

    That wonderful feeling of making the password hard to guess, but easy to recall.

    1. Re:Ah. balance by JebusIsLord · · Score: 4, Insightful

      Yeah, instead you have to worry about the locations of their memory keys!

      --
      Jeremy
    2. Re:Ah. balance by arivanov · · Score: 4, Insightful

      Ahem.

      That was my first reaction as well. If you are using ssh, passwords are "the wrong idea" (TM). A password is guessable while a private key is not. That is the way it is designed.

      Not that it would have helped in this case though. The attacker compromised the developer machine first and from there on compromised the server. Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.

      While at it, I can also understand an admin on a large linux shell machine which still allows passwords.

      Due to Theo and Co's knee jerk (hello Theo) attitude to non-OpenBSD OSes there is no way to make ssh public key authentication plug cleanly in the OS authentication chain. The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux without "OpenBSD is better TM)" being involved it will have to support PAM properly, natively, all the way and for all authentication methods including public keys. This is the way of the land.

      As this is not the case yet, if you want to limit access to public key only you have to turn off PAM for ssh. Alternatively, if you manage a big machine (or network) and you need PAM you end up turning on passwords and praying.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    3. Re:Ah. balance by Mark+Hood · · Score: 4, Insightful

      Not in this case - if you read the summary, even.

      They got in with a developer's password, then used a local exploit to get root permissions.

      I.e. they didn't know (or need to know) the root password. So in this case, having two 8 character passwords was exactly as secure as having one 8 character password.

      Mark

      --
      Liked this comment? Why not buy me something nice
  2. back to normal by Coneasfast · · Score: 4, Insightful
    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.
    Um. What exactly does this mean? If everything isn't back to normal, shouldn't they lock out ALL developers? That's what I would do.
    --
    Marge, get me your address book, 4 beers, and my conversation hat.
  3. password requirements by PetriBORG · · Score: 5, Insightful

    Hopefully then they will also implement a good set of password rules and enforce them to protect themselves from future problems. Where I work they require 3 out of the 4 rules to be met such as mixed case, numbers and special characters... of course they also make us change our password every 30 days so i've discovered that people have taken to doing things like Asdf1234 and then when the password requires changing changing it to Asdf2345... Doh.

    --
    Pete/Petri "damn, my chainsaw is clogged with 1's and 0's again." --clyde
  4. I wonder... by MSFanBoi2 · · Score: 4, Insightful

    Why when this happens on a Windows server is "OMG! Windows is insecure! M$ is evil!!!!"

    But with this its "Oh just set more difficult passwords"...

    1. Re:I wonder... by Anonymous Coward · · Score: 5, Insightful

      Did you fail to understand what a remote exploit is?

      Here, let's try an analogy. In this case someone left the door to the building unlocked. A burglar got in. He then methodically cracked the safe, and took the money from within.
        Following this, "MSFanBoi" posts to slashdot making a false equivalency between that and the Win building where the locks were defective and the money was taken from where it was sitting on the floor. (The windows exploits being criticised are remote, the linux exploit was local-only. In the latter, you have to actually break in before they are useful.)
        Do you still fail to see the difference?

  5. ssh2 keys? by saleenS281 · · Score: 5, Insightful

    Why don't they just have the developers use ssh2 keys? I didn't know anyone actually used passwords on secure systems for authentication...

  6. Re:So? by TCM · · Score: 4, Insightful

    How the hell could this be modded insightful? The whole point of changing passwords is so that the compromise of one password doesn't lead to unlimited access or the compromise of future passwords.

    If a password is so secure that it can't be guessed, then why change it? If it's so weak that it gets guessed monthly, changing just one digit doesn't do shit.

    And if the system gets compromised, you reinstall and choose a totally different password.

    Seriously, this must be the most stupid advice I've seen and it's currently +2, Insightful. Scary.

    --
    Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
  7. Re:Weak Passwords ?? If they know that ...well by Anonymous Coward · · Score: 4, Insightful

    Believe me, the Debian project does not store passwords in the clear.

    As administrators they have access to the shadow file that contains hashed versions of all the passwords. What they did was run a cracking utility against the shadow file to pick out weak passwords. Usually these cracking utilities use brute force dictionary attacks to try and randomly guess the password. If the utility was able to guess a password quickly, that password was definitely not secure. It's as simple as that.

    I encourage you to read more about the topic, it's a fascinating one. Wikipedia has an interesting article at http://en.wikipedia.org/wiki/Password_cracking/.

  8. Re:libpam-cracklib by teslar · · Score: 4, Insightful
    You're laughing, but in practice I have too often seen restrictions on the maximal security of passwords.
    Take for instance my online banking system (which in its defense has other security measures alongside the password, but still):
    • no more than 10 characters please
    • upper/or lowercase does not matter, lowercase will automatically be converted to uppercase
    • alphanumeric characters only

    Seriously, what's the point of this?? Why am I forced to use weak passwords just because some developper somewhere can't figure out how to allow a " or a \ in a string?
  9. howto: strong passwords by dune73 · · Score: 5, Insightful

    If you are in need of a strong password, use the following recipe:

    Think of a sentence with 6-10 words with a number in it.
    - The number can be inside one of the words.
    - If you manage to have multiple Capital words in the sentence, your password gets stronger.

    Then take the first letter and write the numbers as digit, include the point,
    question mark, exclamation point at the end and you got a strong password.

    Today i ate two buns for breakfast! -> Tia2bfb!
    I have seen six dups on Slashdot this week. -> Ihs6doStw.
    Can you memorize all four new passwords? -> Cyma4np?
    And today: A new password for my debian account! -> At:1npfmda!

    Works fine for me and is fairly easy to memorize.