• AbouBenAdhem@lemmy.world
    link
    fedilink
    English
    arrow-up
    180
    arrow-down
    1
    ·
    edit-2
    11 months ago

    Interpreting “a previously-unrecognized weakness in X was just found” as “X just got weaker” is dangerously bad tech writing.

    • Kid_Thunder@kbin.social
      link
      fedilink
      arrow-up
      45
      ·
      11 months ago

      In my opinion Dan Goodin always reports as an alarmist and rarely gives mitigation much focus or in one case I recall, he didn’t even mention the vulnerable code never made it to the release branch since they found the vulnerability during testing, until the second to last paragraph (and pretended that paragraph didn’t exist in the last paragraph). I can’t say in that one case, it wasn’t strategic but it sure seemed that way.

      For example, he failed to note that the openssh 9.6 patch was released Monday to fix this attack. It would have went perfectly in the section called “Risk assessment” or perhaps in “So what now?” mentioned that people should, I don’t know, apply the patch that fixes it.

      Another example where he tries scare the reading stating that “researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.” which is fine to show how prevalent the algorithms are used but does not mention that the attack would have to be complicated and at both end points to be effective on the Internet or that the attack is defeated with a secure tunnel (IPSec or IKE for example) if still supporting the vulnerable key exchange methods.

      He also seems to love to bash FOSS anything as hard as possible, in what to me, feels like a quest to prove proprietary software is more secure than FOSS. When I see his name as an author, I immediately take it with a grain of salt and look for another source of the same information.

    • conciselyverbose@kbin.social
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      11 months ago

      I get your point that the exploit existed before it was identified, but an unmitigated exploit that people are aware of is worse than an unmitigated exploit people aren’t aware of. Security through obscurity isn’t security, of course, but exploiting a vulnerability is easier than finding, then exploiting a vulnerability. There is a reason that notifying the company before publicizing an exploit is the standard for security researchers.

      You’re right that it’s never an OK title, because fuck clickbait, but until it’s patched and said patch propagates into the real world, more people being aware of the hole does increase the risk (though it doesn’t sound like it’s actually a huge show stopper, either).

      • wewbull@feddit.uk
        link
        fedilink
        English
        arrow-up
        9
        ·
        11 months ago

        Also, finding an exploit means the system will get stronger very shortly.

      • AbouBenAdhem@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        11 months ago

        Weakness and risk are distinct things, though—and while security-through-obscurity is dubious, “strength-through-obscurity” is outright false.

        Conflating the two implies that software weaknesses are caused by attackers instead of just exploited by them, and suggests they can be addressed by restricting the external environment rather than by better software audits.

  • Synthead@lemmy.world
    link
    fedilink
    English
    arrow-up
    67
    arrow-down
    1
    ·
    11 months ago

    ChaCha20-Poly1305 and CBC with Encrypt-then-MAC ciphers are vulnerable to a MITM attack.

    Saved you a click.

      • thisisawayoflife@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        11 months ago

        Just checked my own sshd configs and I don’t use CBC in them. I’ve based the kex/cipher/Mac configs off of cipherlist.eu and the mozilla docs current standards. Guess it pays to never use default configs for sshd if it’s ever exposed to the Internet.

        Edit: I read it wrong. It’s chacha20 OR CBC. I rely heavily on the former with none of the latter.

    • NateNate60@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      I thought most SSH servers default to some AES-based cypher like most other programs. Is that not the case?

  • Kid_Thunder@kbin.social
    link
    fedilink
    arrow-up
    61
    ·
    11 months ago

    Since he doesn’t mention it in his ‘fantastic’ reporting, OpenSSH 9.6 was released Monday that will patch this attack. Also, since he doesn’t mention it, if on the Internet, the MITM would have to be installed at both end points (client side and server side) to be effective without the patch.

    • Arthur Besse@lemmy.mlM
      link
      fedilink
      arrow-up
      17
      ·
      11 months ago

      Since he doesn’t mention it in his ‘fantastic’ reporting, OpenSSH 9.6 was released Monday that will patch this attack.

      I am tempted to delete this post just for the article’s stupid clickbait headline, but it still will probably cause some people to go update their OpenSSH installs, so… meh.

      Anyone who actually wants to know details of the vulnerability should read the website about it which is obviously much better than this article.

      Also, since he doesn’t mention it, if on the Internet, the MITM would have to be installed at both end points (client side and server side) to be effective without the patch.

      Huh? No. The attacker doesn’t need to be in two places or even near either end per se, they could be located at any fully on-path position between the client and server.

  • mumblerfish@lemmy.world
    link
    fedilink
    arrow-up
    27
    ·
    11 months ago

    So you need an MitM situation to even be able to perfom the attack, and the the attack on works on two ciphers? The article says those ciphers are commonly enabled, but are they default or used in relatively modern distributed versions of openssh?

    • gerdesj@lemmy.ml
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      11 months ago

      A scan performed by the researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.

      That means a client could negotiate one or the other on more than half of all internets exposed openssh daemons.

      I haven’t got too whizzed up over this, yet, because I have no ssh daemons exposed without a VPN outer wrapper. However it does look nasty.

  • bartolomeo@suppo.fi
    link
    fedilink
    arrow-up
    20
    ·
    11 months ago

    Ylönen, who at the time knew little about implementing strong cryptography in code, set out to develop the Secure Shell Protocol (SSH)

    TIL SSH was invented by a Finn. I swear that country has the most awesome per capita of any country on earth.

    • ouch@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      11 months ago

      Long dark winters when everyone is home without socializing with people. You have got to come up with something to survive until the two week summer.

    • ouch@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      Long dark winters when everyone is home without socializing with people. You have got to come up with something to survive until the two week summer.

  • V ‎ ‎ @beehaw.org
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    11 months ago

    I expect better of Ars. Absolute clickbait title and sensationalism. You need a two point MITM and even then it’s not a magic shell.

  • AutoTL;DR@lemmings.worldB
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    2
    ·
    11 months ago

    This is the best summary I could come up with:


    Once in place, this piece of dedicated hardware surreptitiously inhaled thousands of user names and passwords before it was finally discovered.

    Ylönen, who at the time knew little about implementing strong cryptography in code, set out to develop the Secure Shell Protocol (SSH) in early 1995, about three months after the discovery of the password sniffer.

    As one of the first network tools to route traffic through an impregnable tunnel fortified with a still-esoteric feature known as “public key encryption,” SSH quickly caught on around the world.

    Today, it’s hard to overstate the importance of the protocol, which underpins the security of apps used inside millions of organizations, including cloud environments crucial to Google, Amazon, Facebook, and other large companies.

    Now, nearly 30 years later, researchers have devised an attack with the potential to undermine, if not cripple, cryptographic SSH protections that the networking world takes for granted.

    The attack targets the BPP, short for Binary Packet Protocol, which is designed to ensure that adversaries with an active position can’t add or drop messages exchanged during the handshake.


    The original article contains 658 words, the summary contains 178 words. Saved 73%. I’m a bot and I’m open source!

    • fraksken@infosec.pub
      link
      fedilink
      arrow-up
      10
      ·
      11 months ago

      you missed this part:

      For Terrapin to be viable, the connection it interferes with also must be secured by either “ChaCha20-Poly1305” or “CBC with Encrypt-then-MAC,” both of which are cipher modes added to the SSH protocol (in 2013 and 2012, respectively). A scan performed by the researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.

      • steventhedev@lemmy.world
        link
        fedilink
        arrow-up
        6
        arrow-down
        1
        ·
        edit-2
        11 months ago

        Also that in order to exploit this it requires an active man in the middle. Which requires any of the following:

        • Reverse proxy hijack/NAT hijack - from a compromised machine near the server
        • BGP hijack - stealing traffic to the real IP
        • DNS hijack - stealing traffic to send to a different IP
        • Malicious/compromised network transit
        • Local network gateway control
        • WAP poisoning - wifi roaming is designed really well so this is actually easier than it sounds.

        Almost all of those have decent mitigations like 801.x and BGP monitoring. The best mitigation is that you can just change your client config to disable those ciphersuites though.