*sshole · sshhole.com
sshhole.com
openssh on musl linux has been letting people into password-less accounts since 2016.
  • soyslurper2@lemmy.dbzer0.com
    3·
    3 hours ago

    CVE-2016-6210. ask sshd about a user that doesn’t exist and it says no instantly, cause there’s nothing to hash. [The solution is] sshd grabs some other account’s salt and hashes your password anyway

    I’m not sure how this is relevant to what caused this bug. Seems to me like a random point that was added by the AI writing this blogpost without human review.

    • patatahooligan@lemmy.world
      2·
      1 hour ago

      The article doesn’t clearly explain how all of these fit together, but here’s what I think they mean happens:

      • Attacker tries to connect on a user account that should not accept a password, ie the user’s hash is “*”.
      • This should be outright rejected (“*” means no password login), but because of the point you highlighted, it just grabs a random salt and tries to calculate the password hash anyway.
      • The password is too long so it gets automatically rejected… with the magic value “*”.
      • User hash is “" and the “calculated” hash is also "”, so login accepted.

      Without the “fix” of using another user’s salt, the process would fail immediately for a password-less account. Note that the other user’s salt never plays a role in the calculation because the password is too long and the hash function doesn’t bother calculating it. But it’s the reason execution continues and allows the rest of the bad behaviors to accept the login.

      In hindsight, the mistakes are pretty silly. They shouldn’t actually care if the hash matched the user’s hash if they are one the codepath that is only performing the hash to waste time. Long passwords should be rejected earlier as invalid user inputs instead of reaching the hash functions. These decisions are basically saying “I’m going to do something stupid, but it shouldn’t affect anything because the other parts of the code are surely not doing something stupid at the same time”. It’s obvious why this design philosophy didn’t scale.

  • everett@lemmy.ml
    7·
    7 hours ago

    openssh on musl linux (alpine, openwrt, buildroot, yocto, and a lot of the docker images you’ve pulled)

  • RedSnt ♾️🦋♂️👓🖥️🐧@feddit.dkEnglish
    5·
    7 hours ago
    I have 4 accounts on my OpenWRT router with * as their password, but I did try with a random password over 256 characters and I couldn't log into them. 
    daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false

    Still, this is a huge security flaw!

      • RedSnt ♾️🦋♂️👓🖥️🐧@feddit.dkEnglish
        2·
        3 hours ago

        You’re absolutely right. I just read the article and as it pointed out OpenWRT I wanted to make sure and tested it anyway. OpenWRT doesn’t even have any SSHD packages available, so that’s good. But as I’ve installed the OpenSSH-sftp-server package quite a few times I probably got confused on top of that as well.

    • SavvyWolf@pawb.socialEnglish
      21·
      3 hours ago

      Attacker hacks into a system, sees that it’s running a GPL libc rather than a MIT libc and then politely excuses themselves because they aren’t willing to share their spoils.

      Bad code is bad code, no matter what license it’s written in.

    • N.E.P.T.R@lemmy.blahaj.zoneEnglish
      132·
      6 hours ago

      musl is far more POSIX compliant, secure, and cleaner code (no dirty hacks) than glibc. Not everything has to be a culture war. Do you use sudo (ISC-style)? Do you use curl (MIT-style, curl license)? Even OpenSSH isn’t GPL (BSD). Not everything is a plot; vulnerabilities happen regardless of what license you pick.