Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Debian Locks Out Developers 331

Posted by CowboyNeal from the in-the-name-of-safety dept.
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.
This discussion has been archived. No new comments can be posted.

Debian Locks Out Developers More

Debian Locks Out Developers

Comments Filter:

  • Ah. balance (Score:5, Insightful)

    by Kid Zero ( 4866 ) on Thursday July 13, 2006 @10:27PM (#15716580) Homepage Journal
    That wonderful feeling of making the password hard to guess, but easy to recall.

    • Re:Ah. balance (Score:2, Interesting)

      by eklitzke ( 873155 )
      The obvious alternative is to completely disable password based ssh authentication, and force everyone to use public/private key authentication. That way you don't have to worry about the strength of your users passwords.

      • Re:Ah. balance (Score:5, Insightful)

        by JebusIsLord ( 566856 ) on Thursday July 13, 2006 @11:44PM (#15716896)
        Yeah, instead you have to worry about the locations of their memory keys!

      • Re:Ah. balance (Score:5, Insightful)

        by arivanov ( 12034 ) on Friday July 14, 2006 @01:18AM (#15717135) Homepage
        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.

        • Re:Ah. balance (Score:3, Insightful)

          by KiloByte ( 825081 )
          Talking about openssh's security, here's a vital patch:
          -PermitRootLogin yes
          +PermitRootLogin no

          Come on, how in the hell the first can be the default?
          Is it that hard to log in first to your normal user account?

          And don't start on "but having no root and using sudo is better". This is a fallacy, true only if your normal user password and the root one happen to be the same, or you have a root login available from network. Two separate passwords are always better than just one, and forcing people to type "sudo"

          • Re:Ah. balance (Score:3, Informative)

            by zerblat ( 785 )
            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.

            • Re:Ah. balance (Score:5, Insightful)

              by Mark Hood ( 1630 ) on Friday July 14, 2006 @04:54AM (#15717561) Homepage
              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

            • Re:Ah. balance (Score:5, Informative)

              by BecomingLumberg ( 949374 ) on Friday July 14, 2006 @06:31AM (#15717724)
              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.

          • Re:Ah. balance (Score:3, Insightful)

            by arivanov ( 12034 )
            With passwords you are absolutely correct. Direct root login is stupid, wrong and insecure and people leaving it should be shot.

            With public key authentication for remote access + plain passwords on the machine itself you are not correct. There is no significant difference between giving direct ~/.ssh/authorized_keys based root to all the people entitled to root and giving them access with per user ~./ssh/authorized_keys and su/sudo. The simple password is inherently less secure authentication method compare

          • Re:Ah. balance (Score:5, Informative)

            by aymanh ( 892834 ) on Friday July 14, 2006 @08:04AM (#15718099) Journal
            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.

        • Re:Ah. balance (Score:3, Insightful)

          by Bogtha ( 906264 )

          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 supp

    • Am I the only one that simply got used to memorizing random passwords?

      • Re:Ah. balance (Score:3, Informative)

        by DMUTPeregrine ( 612791 )
        I use <a href=http://keepass.sourceforge.net/>Kee pass</a> 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&#222;Em&#162;f:]&&#198;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
        • People really need to think about how their product names parse when the words are run together and all one case. This is a particularly bad case, because there is only one way to parse "keepass" into real English words, and it's not the way they wanted. I'm sure they liked the idea of sharing the last letter of the first word with the first of the last, and sometimes it works. Other times, though, you end up naming your project "Keep Ass"
      • I like nice, long, random passwords. 16+ characters. I have no problem remembering them, and I use dozens for lots of different things.

    • Re:Ah. balance (Score:5, Funny)

      by finiteSet ( 834891 ) on Friday July 14, 2006 @12:49AM (#15717067)
      That wonderful feeling of making the password hard to guess, but easy to recall.
      If you are like me, it seems like almost everyday the bank or eBay is emailing about a new upgrade to the system, one that requires entering your old and new passwords, social security numbers, bank account numbers, and so on. Accordingly, I've developed some simple tips for coming up with making a hard-to-crack but easy-to-remember password:
      • Short but strong: you can make the password relatively short (e.g. one character) so that it is easy to remember, but random enough to be hacker-proof. Do you really think someone would guess 'q' or 'z' ?
      • Long but simple: if you are unsatisfied with the previous strategy, try this one on for size: the longer the better. So instead of 'a', you might want to use 'aaaaaaaaaaaa'. ('0000000' works, too.)
      • Mirror Mirror: use your username as your password and cut the memory load in half!
      • Long and strong: for the absolutely mission critical stuff, you may have to spice it up. Pair a common dictionary word, like 'dog', 'log' or 'hog' with a small digit ('1', '2', and so on), and you're golden.
      • Final Notes: don't forget to recycle your old passwords and - please - keep a public list!

    • Re:Ah. balance (Score:5, Funny)

      by Millenniumman ( 924859 ) on Friday July 14, 2006 @01:14AM (#15717118)
      "and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises."

  • back to normal (Score:5, Insightful)

    by Coneasfast ( 690509 ) on Thursday July 13, 2006 @10:31PM (#15716602)
    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.

  • kernel exploited... (Score:5, Informative)

    by scum-e-bag ( 211846 ) on Thursday July 13, 2006 @10:35PM (#15716618) Homepage Journal
    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

  • libpam-cracklib (Score:5, Funny)

    by dduardo ( 592868 ) on Thursday July 13, 2006 @10:37PM (#15716627)
    Time to enforce a 200 character minimum for passwords.
    • And while you're at it, no repeated characters either. Time to break out the chinese input program!
    • It's called public-key authentication. Well, 1024-bit keys ~= 128 characters... but that's not quite the same thing really.
      • 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.

    • Re:libpam-cracklib (Score:5, Insightful)

      by teslar ( 706653 ) on Friday July 14, 2006 @05:43AM (#15717643)
      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?

  • password requirements (Score:5, Insightful)

    by PetriBORG ( 518266 ) on Thursday July 13, 2006 @10:38PM (#15716628) Homepage
    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.

    • Secure Passwords lead to Insecure Passwords (Score:5, Interesting)

      by cloricus ( 691063 ) on Thursday July 13, 2006 @11:02PM (#15716736)
      I have noticed what you talk about though I've seen it go to further extremes. While at work (we run a mainly Windows network with a few hundred users) I've done further education (out side of Uni) at Australian TAFEs (basically vocational collages) in Queensland - the TAFE I went to runs a pure Windows network with around twenty thousand plus users over several sites...Any one who has been to one of these TAFEs understands how much of a raping they have taken from Microsoft, and I say raping because they run the 'perfect Windows network' following all of Microsoft guidelines etc which mean some machines take over fifteen minutes to log in and are laggy as all hell once they are in.

      Anyway onto the topic. They also follow the recommended guidelines for passwords which includes at least one capital, two numbers, over six chars, and cannot be any of your previous passwords (with I believe a 80% match so you can't just add a 1 or a 2 to it) and these roll every thirty days. Now as a geek I have my own unique password system where no two are the same, they are long, and they have numbers, and at least one capital - unfortunately there is only five or six possible combinations that meet the password system for each item meaning after five months going to this TAFE (I was there a year part time) I ran out of passwords. This put me on the tred mill that every one else had been on for a few months (they did a fresh roll over to XP from 98 at the start of last year) of forgetting the password (that I made up to get into the system after my old one expired) or where I wrote it down (yes, every one wrote down their passwords in blatant places so they could find them again, which to me makes passwords null anyway) and then starting to use generic passwords that every one else was using that month for example t4f3IsShit or fUkp455words and the like. As you can probably see this just ends up a mockery of the idea.

      So basically the point I'm trying to make is you have to be careful with what you mean by a 'good set of password rules' as if you go overboard even to the slightest extent (as I've seen happen time and time again) passwords just become a joke and you may as well not have them.

      Personally I've found that if you teach people/users what a secure password is, teach them not to tell it to any one, get them to use firefox to avoid keyloggers, and then enforce a six to twelve month roll over no problems ever come up. That's my happy medium and 2cents anyway. :)
    • "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."

      Even so, the use of caps and symbols open the universe of possible characters in a password so as to make brute forcing harder and dictionary attacks neigh impossible. Who the heck keeps As
    • Or even better, they'll realise that the whole concept of passwords is broken and they'll start using private/public keys like everyone else with an internet-connected machine who cares about security.

      • But... (Score:2)

        by XanC ( 644172 )

        Doesn't that mean that if somebody should somehow get into my desktop, either physically, over the network, an old hard drive, etc, and grabs my key, he will have access to every single machine I can access? And I'd have to make a change on each one of those systems?

        I'd really like to switch to keypairs for authentication but that seems inherently dangerous. Am I missing something?

        • You can password protect your keys.

          Yes, if someone nabs your key, it's a risk. The password will slow them down however, and if you notice that you've been r00ted and suspect you've had a key stolen, you should generate a new pair.

          Also, what i used to do at my previous employer where i used keys, was store my private key on my USB memory stick, and only plug it in when i'm likely to be using it.

          That way I can carry it with me, and someone needs to steal it, then know what it is, before they can use i

          • One thing i forgot. If you suspect your private key is compromised, you should of course ALSO tell anyone who uses the public-key half of it (ie, any admin of a machine you've sent your public key to) to revoke it's access.
        • If someone finds out your password (and you use it for a lot of remote systems), you need to change it on all those remote systems. In this respect, a public/private key pair is no different... :-\ You'll need to install/send the new public key to each system.

          • Thanks for your replies; they've got some good usage tips (I hadn't considered password-protecting the key!). One of my main concerns was that while I memorize my password and it is not stored in the computer at all, the private key is. But if there's a password on the key, that's close to the best of both worlds.

            And you're right, of course, that a compromised password and a compromised key both require remote systems to disable access for that token. Of course, one is supposed to use a different passwo

    • Re:password requirements (Score:5, Interesting)

      by Bostik ( 92589 ) on Friday July 14, 2006 @01:14AM (#15717117)

      Hopefully then they will also implement a good set of password rules and enforce them...

      I have a suggestion. Dump the password based access altogether. These are Debian developers, who by their position already NEED to both know and understand how to use GPG for signing their uploads. The concept of public-key access control/validation is their bread and butter.

      Allow only public-key SSH access to Debian machines. Period.

      That way, to compromise Debian server(s), any potential attacker would need to daisy-chain their targets. Break a developer's home or work box first, get their keys and their passphrases. Only then can they proceed to bigger targets.

    • That's why you should not require people to change their password.

      Yes I know everyone tells you it's important - they are wrong. Unless you are in the millitary requiring poeple to frquently change their passwords leads to WEAKER passwords.

      I've seen it over and over, they'll pick easy to remember (and thus crack) passwords, write them down, use the same password everywhere, all kinds of bad things.

      Make them set ONE good password, and leave it like that.

  • I wonder... (Score:4, Insightful)

    by MSFanBoi2 ( 930319 ) on Thursday July 13, 2006 @10:42PM (#15716641)
    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"...
    • Buddie, you're name isn't helping your case one bit.

      But the sad thing is...he's right.
      • Actually, no he's not.

        This wasn't a remote exploit.

        If you give away logins on any machine, people will likely be able to use some local exploit to own the box.

        Most of the Windows security problems we bitch about involve REMOTE exploits with no user account necessary.

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

      Don't forget that people would be making fun of the incompetent MCSE admin for not enforcing a complex password policy

  • If only they'd... (Score:5, Funny)

    by a_greer2005 ( 863926 ) on Thursday July 13, 2006 @10:46PM (#15716661)
    been running with the stability and security of Windows Server, they wouldnt have had this happen. They would have kept their service up and agile for the furtherance of the enterprising endvors of hacking...er...uhhh...computer science research.

    Bill G.

  • ssh2 keys? (Score:5, Insightful)

    by saleenS281 ( 859657 ) on Thursday July 13, 2006 @10:52PM (#15716682) Homepage
    Why don't they just have the developers use ssh2 keys? I didn't know anyone actually used passwords on secure systems for authentication...

    • Re:ssh2 keys? (Score:4, Insightful)

      by Gregg Alan ( 8487 ) on Thursday July 13, 2006 @11:02PM (#15716738)
      Why don't they just have the developers use ssh2 keys? I didn't know anyone actually used passwords on secure systems for authentication...

      Agreed. Don't we all know this already? I don't have anywhere near the number of users that Debian does, but it's keys all the way.

      On the other hand, if they used a weak password for something as serious as Debian developer access who's to say that their workstation/personal network/whatever wouldn't be compromised and leak the encrypted key and then the key (assuming they have a weak passphrase).

      I smell a sleeper.
      • However, said keys better be passphrase- (NOT password-) protected! After all, if, let's say, $DEVELOPER's laptop gets stolen and it has a non-passphrase-protected ssh key, then going to the effort of using keys for authentication will be for naught.

        FWIW, I recently ditched Debian for a completely unrelated reason (see also, CVE-2006-1173).

    • SSH keys are not a cure-all. In fact, they can be worse than passwords.

      Yes worse. Ssh keys are not certificates -- they don't expire and are not revokable. So, if someone compromises your private key, they get access to every host that has your pub key until you visit each host and delete the offending key. Add to this the fact that users can (and often do) create ssh keypairs without putting a password on the private key and the fact that there's no way for an admin to detect and inforce password prote

      • Re:ssh2 keys? (Score:3, Interesting)

        by AirLace ( 86148 )
        Sure, but that's why every Debian developer has to have a GPG key. It's a requirement of the project, and GPG keys are proof of identity and revocable, and what's more, they can be used to sign SSH keys. That's how freedesktop.org works, and that's how Debian would have been working today if its hierarchy of command hadn't crumbled years ago and someone were actually in the position to mandate that logins should be done by PKI.

        That said, pretty much everything else in the Debian project appears to work fine
  • "An investigation of developer passwords revealed a number of weak passwords whose accounts have been locked in response," Schulze wrote.

    An investigation? Doesn't it a long time to bruteforce properly encrypted passwords? How did they carry out this 'investigation'?

    Can somebody please cure me of my chronic ignorance?

  • B...b...b... (Score:5, Funny)

    by htnprm ( 176191 ) on Thursday July 13, 2006 @10:59PM (#15716726) Homepage
    ...but it's Linux!

  • good idea (Score:4, Insightful)

    by smash ( 1351 ) on Thursday July 13, 2006 @11:23PM (#15716830) Homepage Journal
    I mean, it's one thing to use an insecure password on your personal machine - but using an insecure password on a common development machine for a fairly high profile project is just irresponsible.

    Locking them out is totally fair, and imho it's the responsible thing to do.

    STRONG passwords should be enforced (hell, mandatory keyed logins would be better) on machines like this (which are fairly attractive targets for abuse)...

  • For once it's not a compromised windows based system we're waiting for a bug fix on...

  • *gasp*! (Score:5, Funny)

    by grasshoppa ( 657393 ) on Thursday July 13, 2006 @11:33PM (#15716854) Homepage
    Goodness, no! This might push them behind schedule!
  • Debian locks out developers after server hack

    How much more useful would have been the headline Debian closes accounts with weak passwords?
  • They rely on the slightly more secure method of ssh keys.
  • 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.

  • Chip and Pin (Score:5, Funny)

    by giafly ( 926567 ) on Friday July 14, 2006 @05:17AM (#15717600)
    I use my credit card Chip and Pin number as my password. If you do the same, you'll be completely secure, because it's the one thing that cannot be forged. Don't just take my word for it, check out these quality endorsements:

  • Overreacting a bit? (Score:3, Insightful)

    by rai4shu2 ( 987626 ) on Friday July 14, 2006 @05:49AM (#15717655)

    "Due to the short window between exploiting the kernel and Debian admins noticing, the attacker hadn't time/inclination to cause much damage," wrote Schulze.

    "The only obviously compromised binary was /bin/ping. The compromised account did not have access to any of the restricted Debian hosts. Hence, neither the regular nor the security archive had a chance to be compromised."

    It seems like nothing much really happened. I mean, if this is all a hacker is capable of even with root access to a major Debian server, then what's all the fuss about?

  • howto: strong passwords (Score:5, Insightful)

    by dune73 ( 130598 ) on Friday July 14, 2006 @06:49AM (#15717772) Homepage
    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.

    • 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 s

  • Again? (Score:3, Insightful)

    by wobblie ( 191824 ) on Friday July 14, 2006 @08:09AM (#15718122)
    As a long time Debian user I am not so surprised by this - it is just the reality when you operate a system with thousands of user & shell accounts all over the world. It isn't that big of a deal if the debian admins respond correctly, which they always do, but it looks bad.

    The issue that gets me is this is the second time the Debian system has been compromised, and in the exact same way - a local kernel exploit from a compromised DD account. As good as the Debian security team is, they are frankly terrible with the kernel. The Linux kernel has continual local security exploits (I am not in denial about that); these don't matter so much for most deployments but for the Debian system they are absolutely critical because of all the shell accounts. The Debian kernel team really needs to work out something better (though I know the issue is more complicated than that); this is the one thing Red Hat does very well. I cannot for the life of me understand why debian servers kernels are not upgraded continually. The downtime is immaterial compared to something like this.

    • Re:Again? (Score:3, Insightful)

      by noahm ( 4459 )
      As good as the Debian security team is, they are frankly terrible with the kernel.

      The servers compromised, in both cases, were not running kernels supported by the debian security team. The Debian sysadmin people typically roll their own kernels for use on Debian.org machines. In fact, had the default stable kernel been used, the machine would not have been vulnerable to this exploit. See http://lists.debian.org/debian-news/debian-news-2 0 06/msg00030.html [debian.org] for more info. (In short, 2.6.8 is not vulnera

  • Passwords? Are you nuts ? (Score:3, Insightful)

    by m.dillon ( 147925 ) on Friday July 14, 2006 @02:09PM (#15720912) Homepage
    There shouldn't be any passworded accounts on a developer machine at all. It should be SSH access via public key only, period end of story. I stopped using remotely accepted passwords over a decade ago. Passwords are only accepted on the console.

    Come on, folks. This is UNIX-101. Don't be stupid.

    -Matt

Slashdot Top Deals

Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. - Oscar Wilde

Close