*sshole · sshhole.com
sshhole.com
openssh on musl linux has been letting people into password-less accounts since 2016.
  • lobsters__schue_9625@crustaceanson.theshelf.topM
    1·
    3 days ago

    I really don’t like this style of writeup. In general, I mean (this AI website and writeup style, and the story and list style) but also this one in particular.

    It mentions many things without really explaining how things come together. For instance, it’s unclear why the fact that SSH checks another user’s hash to avoid enumerating users is relevant. Is it because SSH previously detected a hash of * outright and now it’ll do the hash anyways? Why does this require another user? The next section’s titled “the fix for the fix”, but this doesn’t fix something that was previously mentioned. Do they mean that switching to * after ! is “the fix for the fix”? If so, why is the heading that?

    I haven’t looked at the animations much. They seem maybe fine but completely unnecessary. I don’t see what they add to the post.

    In general, segmenting this as a timeline makes little sense, since you’re simultaneously trying to walk through the steps to the exploit and giving a history of how that came to be, which aren’t the same thing. Scrolling a long distance between the parts is also very annoying.

    I am somewhat offended by the faux-authentic lowercase and informal writing. Given how the site looks and that the writeup mentions using AI agent swarms, and the general prose style, it seems likely AI was used to write the text. Why pretend otherwise? The “yes, any password. yes. i know. yes” and “cause there’s nothing to hash” seem really annoying given that it’s almost certainly not expressing any actual whimsy on the part of the author.

    The demo also seems moot because, uh, what’s that supposed to prove? Huh? For all I know you just programmed it to pretend the exploit works. I can spin up an Alpine container myself just fine, thank you very much.

    I also don’t like how the writeup doesn’t mention that PermitRootLogin no and PasswordAuthentication no should really be standard by now.

    score 2 · canonical

  • lobsters__srcrip@crustaceanson.theshelf.topM
    1·
    4 days ago

    Yes the design is a little slop-y, but interesting vulnerability… does this have a CVE then? Not sure how that works. Does this effect anyone running default alpine docker up on the internet then? If you run a docker container with alpine that has ssh installed, are we saying it’s possible to log into the ‘alpine’ user that way by default?

    score 1 · canonical

  • lobsters__gcupc@crustaceanson.theshelf.topM
    1·
    4 days ago

    First thing I do on any server is turn off password authentication, for years, just because of all the automated brute force attempts. I fail2ban them, of course, but there are always more. It can be a pretty big inconvenience when I have a new device, but I’m just living with it.

    score 1 · canonical

  • lobsters__hjvt@crustaceanson.theshelf.topM
    1·
    4 days ago

    Barely coherent animations every three sentences make this a really unfun read. And, is it just me, or do none of the very overly verbose explanations actually ever explain how those behaviors come together to produce a vulnerability? I had to ignore the prose and put the code snippets together to get what actually happened.

    score 8 · canonical

  • lobsters__regal_6269@crustaceanson.theshelf.topM
    1·
    4 days ago

    It’s an interesting vuln, but this glossy website presentation style that buries the lede (am i affected, what to do), is really annoying to read through.

    I know that named-vuln-site itself is a cliche that some people roll their eyes on, but in comparison:

    feel much more grounded and immediately useful than this, but I guess the LLM graphics stuff gets more clicks or something :/

    That checklist at the end is also like… Maybe I’m old-fashioned but I thought it’s not a good UI/UX thing to have things randomly pop-in or blink.

    score 7 · canonical

  • lobsters__dullmirror@crustaceanson.theshelf.topM
    1·
    4 days ago

    That was a fun read!

    Luckily PermitRootLogin hasn’t allowed logins with passwords for root since 2015. I’m guessing that’s at least part of why this went undiscovered for so long.

    For this to hit root I believe you’d have to actively allow password-logins for a root-account that doesn’t have a password, which seems like a weird thing to do. But people are forgetful, so it’s entirely possible to end up in this situation. I’m glad OpenSSH decided to patch even though they “consider the root cause of this bug to be outside sshd”.

    score 3 · canonical

    • lobsters__edwintorok@crustaceanson.theshelf.topM
      1·
      3 days ago

      I think this is a security bug in musl too, and should be fixed there as well. Returning ‘*’ is a particularly bad choice, because that is a valid passwd entry! If it returns any placeholder, it should be something that is not a valid passwd entry.

      score 1 · canonical

      • lobsters__sjamaan@crustaceanson.theshelf.topM
        1·
        3 days ago

        My point is that their “fix” for broken programs that didn’t handle NULL actually created this vulnerability in the first place, which is why I questioned their decision to change it in musl. They could’ve left it at returning NULL. Agreed that now they are doing it like this, they ought to choose some string that could never match any literal string in the password field (a tall order, although a good suggestion I’ve seen on oss-security would be to use :, as that is the field separator and could never itself be stored in the password hash field).

        score 1 · canonical

    • lobsters__johz@crustaceanson.theshelf.topM
      1·
      4 days ago

      I suspect because this is a fairly rare thing to happen that most people don’t think about it when testing their programs, and so don’t handle that case correctly. And if you have a large number of real-world programs running that already do the wrong thing and crash, then it’s probably easier to fix it at the API level rather than fix all those programs (even if technically those programs are wrong).

      Ideally, they could have used ADTs to force users to handle the error cases or crash explicitly (Ok(String) | Err(UnknownAlgorithm)) but that’s not really viable for a C API unfortunately.

      score 2 · canonical

      • lobsters__sjamaan@crustaceanson.theshelf.topM
        1·
        4 days ago

        Yeah but those programs are more likely used on glibc in the vast majority of systems, which will also return NULL. So musl fixing it unilaterally isn’t going to make as much of an impact as trying to fix the programs.

        score 2 · canonical

        • lobsters__siru@crustaceanson.theshelf.topM
          1·
          4 days ago

          “Fixing” it in musl doesn’t cause incompatibility with programs that would correctly check for null though. So in theory it can be “fixed” from both sides of the API. Musl fixing it in their version is just a step in the right direction. Sadly it caused a bug that now also needs to be fixed.

          score 1 · canonical

  • lobsters__siru@crustaceanson.theshelf.topM
    1·
    4 days ago

    Am I right in understanding that this is fully mitigated by disabling password login and using ssh keys instead? Because that should be the norm nowadays anyway for other reasons as well, right?

    (Not trying to say this shouldn’t be fixed and isn’t a good find though.)

    score 1 · canonical