3 ms·

Not all bugs are memory bugs. A memory-safe re-implementation would likewise introduce many new bugs, so it would not be necessarily better than the battle-tes

Not all bugs are memory bugs. A memory-safe re-implementation would likewise introduce many new bugs, so it would not be necessarily better than the battle-tested current implementation. That said, re-implementations are always cool.

mrweasel 4y ago
If I recall correctly having most of the world relying on a single SSH implementation was raised as a concern by the OpenBSD/OpenSSH developers when HeartBleed happened and OpenBSD forked OpenSSL. A major security problem in OpenSSH would be a huge issue, as it affects everyone at once. If someone where to do a reimplementation in a memory-safe language, and let's face it, that's a sly way of saying Rust, it shouldn't be viewed as a replacement for OpenSSH, but as an alternative to existing along side it.
- Fnoord 4y ago
  > A major security problem in OpenSSH would be a huge issue, as it affects everyone at once. It happened once in OpenSSH (in the '00s), and that's it. Ever since, it got hardened. Same with OpenSSL's Heartbleed. We've adapted to these occurrences.
  - zie 4y ago
    I agree the probability is low, but it's clearly not 0, nor will it ever be 0. Is it close enough to 0 as to be not worth worrying about? I don't know the answer to that question but I'd guess it's far enough away from zero that it could definitely be a concern. Especially since we know that upgrades can be quite slow, especially in the consumer space(if they are ever done at all). Another worry, is now every platform uses OpenSSH (Microsoft, Apple and *nix all use OpenSSH). 22-ish years without a major security problem is a great track record though.
  - knorker 4y ago
    That's not accurate. OpenSSH (and OpenBSD) have a myth around it about lack of security vulnerabilities, but while better than the average, it's wildly exaggerated: Reference: https://www.cvedetails.com/vulnerability-list.php?vendor_id=97&product_id=585&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=97&sha=cf091948bd7a20cd650cfc7fb718a5f4400a6d71 https://www.cvedetails.com/vulnerability-list.php?vendor_id=... I remember people in the '90s and '00s being smug about still being on ssh.com, because something like 75% of vulnerabilities in SSH implementations for a long time were introduced only into OpenSSH.
    - yjftsjthsd-h 4y ago
      Actually reading down those vulnerabilities makes me as confident as ever in it; it has a steady stream of vulnerabilities, but they're almost always things like user enumeration, or a person who already has legitimate access being able to get slightly different access than they were supposed to have. Don't get me wrong, those are still bad, but if you have to go back 20 years to find an actual remote access vulnerability, then I'd say the software is rock solid.
      - knorker 4y ago
        I don't disagree. SSH was already 25 years ago a mature code base with (more importantly) a limited scope and unchanging core requirements. I think its long life and limited scope is more of a factor to its security success than how good the coders were. Once you get out of the simple case of "RCE on pre-auth sshd" OpenSSH is no longer looking as good. E.g. CVE-2019-611 is way underhyped, and the fact that it was only discovered in 2019 doesn't speak well for OpenSSH's audit process. But for "is it safe to open OpenSSH to the world" I'd say "that's safer than anything else, sure". But that's a very narrow (though important) attack vector.
  - tialaramex 4y ago
    The OpenBSD people have a certain perspective on how to write secure code, which certainly is valuable, but misses low hanging fruit that aren't in their vision as a result of that perspective. Safer languages are one of the things out of view for them. At its best, this way of thinking about problems is invaluable because it can cure ills that otherwise affect everyone. OpenBSD has been very enthusiastic about identifying ways programs can avoid having privileges they don't need while retaining ergonomics for example. At its worst though it ignores both categorical improvements like Rust and very niche but targeted security features which don't fit OpenBSD's model like the Certificate Signing Request in PKIX (the document your Let's Encrypt software is just generating internally, once upon a time these were a big deal). OpenBSD works very hard to enable the code signing your CSR to not need the same privileges as the code doing networking, or the code generating the keys - but it's arguably in vain because there's no need for the CSR to even be generated on the machine with the private key, they've welded a fortified cash box to the vending machine, everybody else just added a card reader. "Now nobody can steal the money!" "What money?".

mrweasel 4y ago

If I recall correctly having most of the world relying on a single SSH implementation was raised as a concern by the OpenBSD/OpenSSH developers when HeartBleed happened and OpenBSD forked OpenSSL. A major security problem in OpenSSH would be a huge issue, as it affects everyone at once. If someone where to do a reimplementation in a memory-safe language, and let's face it, that's a sly way of saying Rust, it shouldn't be viewed as a replacement for OpenSSH, but as an alternative to existing along side it.

Fnoord 4y ago
> A major security problem in OpenSSH would be a huge issue, as it affects everyone at once. It happened once in OpenSSH (in the '00s), and that's it. Ever since, it got hardened. Same with OpenSSL's Heartbleed. We've adapted to these occurrences.
- zie 4y ago
  I agree the probability is low, but it's clearly not 0, nor will it ever be 0. Is it close enough to 0 as to be not worth worrying about? I don't know the answer to that question but I'd guess it's far enough away from zero that it could definitely be a concern. Especially since we know that upgrades can be quite slow, especially in the consumer space(if they are ever done at all). Another worry, is now every platform uses OpenSSH (Microsoft, Apple and *nix all use OpenSSH). 22-ish years without a major security problem is a great track record though.
- knorker 4y ago
  That's not accurate. OpenSSH (and OpenBSD) have a myth around it about lack of security vulnerabilities, but while better than the average, it's wildly exaggerated: Reference: https://www.cvedetails.com/vulnerability-list.php?vendor_id=97&product_id=585&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=97&sha=cf091948bd7a20cd650cfc7fb718a5f4400a6d71 https://www.cvedetails.com/vulnerability-list.php?vendor_id=... I remember people in the '90s and '00s being smug about still being on ssh.com, because something like 75% of vulnerabilities in SSH implementations for a long time were introduced only into OpenSSH.
  - yjftsjthsd-h 4y ago
    Actually reading down those vulnerabilities makes me as confident as ever in it; it has a steady stream of vulnerabilities, but they're almost always things like user enumeration, or a person who already has legitimate access being able to get slightly different access than they were supposed to have. Don't get me wrong, those are still bad, but if you have to go back 20 years to find an actual remote access vulnerability, then I'd say the software is rock solid.
    - knorker 4y ago
      I don't disagree. SSH was already 25 years ago a mature code base with (more importantly) a limited scope and unchanging core requirements. I think its long life and limited scope is more of a factor to its security success than how good the coders were. Once you get out of the simple case of "RCE on pre-auth sshd" OpenSSH is no longer looking as good. E.g. CVE-2019-611 is way underhyped, and the fact that it was only discovered in 2019 doesn't speak well for OpenSSH's audit process. But for "is it safe to open OpenSSH to the world" I'd say "that's safer than anything else, sure". But that's a very narrow (though important) attack vector.
- tialaramex 4y ago
  The OpenBSD people have a certain perspective on how to write secure code, which certainly is valuable, but misses low hanging fruit that aren't in their vision as a result of that perspective. Safer languages are one of the things out of view for them. At its best, this way of thinking about problems is invaluable because it can cure ills that otherwise affect everyone. OpenBSD has been very enthusiastic about identifying ways programs can avoid having privileges they don't need while retaining ergonomics for example. At its worst though it ignores both categorical improvements like Rust and very niche but targeted security features which don't fit OpenBSD's model like the Certificate Signing Request in PKIX (the document your Let's Encrypt software is just generating internally, once upon a time these were a big deal). OpenBSD works very hard to enable the code signing your CSR to not need the same privileges as the code doing networking, or the code generating the keys - but it's arguably in vain because there's no need for the CSR to even be generated on the machine with the private key, they've welded a fortified cash box to the vending machine, everybody else just added a card reader. "Now nobody can steal the money!" "What money?".