4 ms·
SSH protects the most sensitive networks. It just got a lot weaker
- supriyo-biswas 3y agoDupe of https://news.ycombinator.com/item?id=38684904 https://news.ycombinator.com/item?id=38684904
- binkHN 3y agoThat's quite the sensationalist title for something that was recently patched.
- ssgodderidge 3y agoAgreed. Also, "just got a lot weaker" is misleading, as the vulnerability already existed, it was just discovered. "was weaker than we thought" is a bit less exciting, but more accurate.
- abtinf 3y agoThe headline is the opposite of the truth: it is now stronger than ever. By the logic of a headline, a person cured of a disease is weaker afterward.
- pas 3y agogoing through a long sickness usually leaves one weaker afterward, even if one is cured, no? and in some cases there might be a slight upside in acquiring a certain degree of protection from future illnesses from that disease through various immunity mechanisms (which are of course far from perfect).
- Filligree 3y agoOkay, yes, that's one way the analogy breaks down.
- eslaught 3y agoIt's more like you always had a disease and just didn't know it. Celiac comes to mind as a common example. I know people who improved a lot once they got diagnosed, and just never realized the symptoms meant anything before that.
- pas 3y agoyep, but that's not curable (yet!)
- commandersaki 3y agoAlso while the attack is novel it is hard to launch in practice (requires MITM) and even if you manage to pull that off, there isn't much to be gained (even with the downgrade for authenticated data to use SHA1 as it isn't practical to attack an interactive session).
- dt3ft 3y agoPatched by how many of the 80% mentioned?
- binkHN 3y agoThe patch was just released two days ago.
- everforward 3y agoI wouldn't get too excited; it requires a MITM so abusing it at scale would be difficult. Big targets should be wary, people's Hetzner servers and VMs are probably safe. They're not worth the effort to get a MITM on.
- progval 3y agoInteresting choice of example, two months ago an organization found their Hetzner server was MITMed https://news.ycombinator.com/item?id=37955264 https://news.ycombinator.com/item?id=37955264
- tw04 3y agoThere are hundreds of thousands of devices out there running older versions of SSH that can't or won't ever be patched. Sure, for folks running a modern full OS that can just patch at will, they're great. I think the title is far less sensational than you give credit.
- taskforcegemini 3y agothese devices should not be directly reachable ovee internet to begin with
- tw04 3y agoBut they are, which is why this is an issue. Posting on HN "don't do that" isn't going to change the reality we live in.
- jvanderbot 3y ago> 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. At this point, I don't even open any ports except whatever required for wireguard, and all services connect on that interface. For the rare times that breaks, all cloud venders have a "virtual" terminal I use. EDIT: services includes ssh. Not sure that was clear from context.
- gh02t 3y agoSame here, running Wireguard on the gateway (pfSense) really streamlined a lot of my needs on the go.
- Suffocate5100 3y agoExactly. I keep everything off the public internet unless it's a website meant to be accessed by millions of people. Nebula is all I use now.
- xoa 3y agoCompletely agreed, and that seems like best practice even at home let alone "the most sensitive networks" which should be running zero trust. Text traffic or even most web interfaces at this point are so lightweight and Noise-based VPNs so performant that even if theoretically there are inefficiencies in running it through other layers of tunnels in practice it's zero issue outside of extreme edge cases. Seems like everything non-public should just be tunneled by default at this point, even when the protocol itself is supposed to be secure. I can't see any downside to adding another layer to the onion in this case, and indeed there are some bonuses IME in terms of ease of routing/NAT hole punch etc to boot. Of course on top is the whole galaxy of gear running never-updated stacks, from UPSs and PDUs to even core stuff like network switches which I've seen linger on completely obsolete cipher choices for ages. Or web GUIs doing the same with HTTPS (if they even support HTTPS(!)). Some stuff arguably should just be airgapped entirely, but if/when that's not possible stuff it behind a lot of layers of protection would be nice. I'd love to see an in-line form factor PoE ultra minimal dongle whose only job in life is to run Wireguard or Nebula or Tailscale or something, translating from that to an ethernet port that any ancient device can talk into and insuring 100% of traffic will go via that or not at all at the hardware level. Then could effectively mediate all traffic even to ancient stuff via that without it ever needing to even hit a switch.
- chasil 3y ago"Terrapin can also override an older extension parameter specifying the use of the SHA2 cryptographic hash function. As a result, SSH will instead use the weaker SHA1." I'm curious if Tinyssh is immune to this attack, since it doesn't implement sha1 (especially as I'm using it in several places). "State-of-the-art crypto: ssh-ed25519, curve25519-sha256, chacha20-poly1305@openssh.com" https://tinyssh.org/ https://tinyssh.org/
- unethical_ban 3y ago"adversary-in-the middle, also known as man-in-the-middle" Hoo boy.
- markhahn 3y agoright, so if you already have a huge security problem, there are a narrow set of cases where this might allow fairly minor weakening of your ssh sessions (if you don't perform the straightforward mitigation).
- PantaloonFlames 3y ago> if you already have a huge security problem, Maybe? If you include "use a third-party hoster" into the idea of "have a huge security problem". From a different comment (https://news.ycombinator.com/item?id=38710214 https://news.ycombinator.com/item?id=38710214) , two months ago an organization found their Hetzner server was MITMed https://news.ycombinator.com/item?id=37955264 https://news.ycombinator.com/item?id=37955264 . The source article says "We believe this is lawful interception Hetzner and Linode were forced to setup." tl;dr: People's assumptions about SSH enabling a secure tunnel are not necessarily valid.
- henriquez 3y agoNewspeak 101: it’s sexist to assume that a malicious actor is male. Women can be malicious too! Other acceptable terms are: Woman-in-the-Middle and Man-or-Woman-or-Non-binary-In-the-Middle. Add that to your allow list.
- unethical_ban 3y agoYeah that's what I was hoo-boying about. The subtle shift in term.
- cratermoon 3y agoAlice, Bob, Eve, Mallory, Trent, and so on. https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characters https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...
- markhahn 3y agonot a lot. first need MITM, and that's not trivial. next need to be running to asyncssh (which has a straight-up bug in its state machine). next need to be running specific ciphers which use the ssh packet sequence number in their IV. it is a moderate big deal because it's a protocol flaw, not just a bug. so the openssh "patch" actually introduces a new protocol option, which doesn't help unless both sides select it.
- keepamovin 3y agoFor anyone who wants to disable the vulnerable primitives, I just made a bash function: #!/bin/bash # Function to apply Terrapin Mitigation to SSH configurations terrapin_mitigation() { echo "Applying Terrapin mitigation to SSH client and daemon config..." # Function to filter algorithms, reading from stdin filter_algorithms() { while read -r alg; do if [[ "$alg" != *"chacha20-poly1305@openssh.com"* ]] && [[ "$alg" != *"-cbc"* ]] && [[ "$alg" != *"-etm@openssh.com"* ]]; then echo "$alg" else echo "Removing vulnerable $alg" >&2 fi done } # Ensure .d directories exist sudo mkdir -p /etc/ssh/sshd_config.d sudo mkdir -p /etc/ssh/ssh_config.d # Get and filter algorithms kex_algorithms=$(ssh -Q kex | filter_algorithms) ciphers=$(ssh -Q cipher | filter_algorithms) macs=$(ssh -Q mac | filter_algorithms) # Create configuration lines kex_line="KexAlgorithms $(echo "$kex_algorithms" | tr '\n' ',')" cipher_line="Ciphers $(echo "$ciphers" | tr '\n' ',')" mac_line="MACs $(echo "$macs" | tr '\n' ',')" # Remove trailing commas kex_line=${kex_line%,} cipher_line=${cipher_line%,} mac_line=${mac_line%,} # Output to sshd.d and ssh.d files echo "" echo "*** /etc/ssh/sshd_config.d/terrapin-mitigation: ***" { echo "$kex_line"; echo "$cipher_line"; echo "$mac_line"; } | sudo tee /etc/ssh/sshd_config.d/terrapin-mitigation echo "" echo "*** /etc/ssh/ssh_config.d/terrapin-mitigation: ***" { echo "$kex_line"; echo "$cipher_line"; echo "$mac_line"; } | sudo tee /etc/ssh/ssh_config.d/terrapin-mitigation echo "" echo "Terrapin mitigation configuration updated!" } terrapin_mitigation Because of the way SSH resolves its config (first of CLI, user local, system wide), in some cases you may prefer to alias ssh to configure this at the command line. Also disabling some algorithms might bar you from connections that are limited to those. I'm not an expert, this is just what I threw together now. You're welcome to use it unless you know a better way. Please suggest improvements if you see them and use at your own discretion otherwise! :)
- throw0101b 3y ago# Ensure .d directories exist sudo mkdir -p /etc/ssh/sshd_config.d sudo mkdir -p /etc/ssh/ssh_config.d Note that this was added in OpenSSH 8.2, released 2020-02-14: * https://bugzilla.mindrot.org/show_bug.cgi?id=2468 https://bugzilla.mindrot.org/show_bug.cgi?id=2468 * https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2 If you have an older version this will not work.
- yellow_lead 3y agoEven the security researcher that reported this doesn't think so. > I am an admin, should I drop everything and fix this? > Probably not. > The attack requires an active Man-in-the-Middle attacker that can intercept... [1] https://terrapin-attack.com/ https://terrapin-attack.com/
- tompic823 3y agoI wonder what impact this will have on Mozilla's OpenSSH configuration guide[0], which currently specifies `chacha20-poly1305@openssh.com` as its primary cipher. Should that be dropped to rely solely on AES ciphers? [0] https://infosec.mozilla.org/guidelines/openssh https://infosec.mozilla.org/guidelines/openssh
- forward1 3y agoGood old RSA once again proves it can be trusted, whereas these newer crypto systems made in the last decade disappoint over and over again. Yet people keep using them because they're told they are fashionable, without really knowing the full implications.
- TontonNestor 3y agoAs far as I can tell, this has nothing to do with the public key cryptography used in the protocol.
- manchmalscott 3y agoFrom the original paper: > ChaCha20-Poly1305 [30] directly uses the sequence number in its key derivation, which makes it vulnerable to our prefix truncation attack... > Note that the fault is not with ChaCha20-Poly1305 as an AEAD encryption scheme, but with its integration into the SSH secure channel construction. See here: https://terrapin-attack.com/TerrapinAttack.pdf https://terrapin-attack.com/TerrapinAttack.pdf