3 ms·

>I am an admin, should I drop everything and fix this? >Probably not. (I will preface this by saying I'm likely missing something obvious.) I am an admin, an

>I am an admin, should I drop everything and fix this? >Probably not. (I will preface this by saying I'm likely missing something obvious.) I am an admin, and it's not clear _how_ I might fix this at the server end. Edit: thanks for the replies, I'll sit tight for now.

justinclift 3y ago
Seems like it'll be a case of "wait for updated ssh packages", potentially with some mitigation advice appearing in the next day or so.
- 1letterunixname 3y ago
  No. Mitigations were available for openssh before you wrote that comment. Follow the recommendations from ssh-audit (master version). [0] For packages, openssh and openssh-portable 9.6 include the fix, but every vendor will need to backport if they maintain their own pile of patches against a particular version of -portable. 0. https://github.com/jtesta/ssh-audit https://github.com/jtesta/ssh-audit
  - justinclift 3y ago
    Thanks, hadn't come across ssh-audit before. Looks like a good tool. :)
gorkish 3y ago
> I am an admin, and it's not clear _how_ I might fix this at the server end. You're just hearing about this early as it's the first hours of public disclosure. There are 3 CVE's assigned. You'll track those with your vendors or upstream and patch as fixes become available, which they already should be for at least some implementations that had earlier disclosure. The main issue is CVE-2023-48795. It does not appear there is any immediate need to implement compensating controls or workarounds at this time, but that assessment really depends on your own environment, security policy, and risk tolerance.
Skrillor 3y ago
We updated the FAQ question to cover this. For most users, fixing can be done by installing patched versions of their SSH implementations as they come available. If you feel uncomfortable waiting for an update, you may disable the affected cipher modes temporarily and use other modes like AES-GCM instead. But keep in mind that a faulty configuration can cause you to loose access to the server.
- colmmacc 3y ago
  Fwiw, I found a bunch of clients and libraries that didn't support AES-GCM at all, or only very recently. libssh2 is one example. That's made me nervous to make AES-GCM the only supported cipher as a mitigation.
  - Aloisius 3y ago
    What about aes-ctr?
    - lambdafu 3y ago
      Depends a bit on the MAC. CTR-EtM is technically vulnerable (i.e. cryptographically broken), but due to key stream desynchronization the attack will quickly lead to application errors, defeating the attacker. See Sect. 4.3.3.
  - shaicoleman 3y ago
    FYI: libssh2 supports AES-GCM since 1.11.0 (released 2023-05-30)

justinclift 3y ago

Seems like it'll be a case of "wait for updated ssh packages", potentially with some mitigation advice appearing in the next day or so.

1letterunixname 3y ago
No. Mitigations were available for openssh before you wrote that comment. Follow the recommendations from ssh-audit (master version). [0] For packages, openssh and openssh-portable 9.6 include the fix, but every vendor will need to backport if they maintain their own pile of patches against a particular version of -portable. 0. https://github.com/jtesta/ssh-audit https://github.com/jtesta/ssh-audit
- justinclift 3y ago
  Thanks, hadn't come across ssh-audit before. Looks like a good tool. :)

gorkish 3y ago

> I am an admin, and it's not clear _how_ I might fix this at the server end. You're just hearing about this early as it's the first hours of public disclosure. There are 3 CVE's assigned. You'll track those with your vendors or upstream and patch as fixes become available, which they already should be for at least some implementations that had earlier disclosure. The main issue is CVE-2023-48795. It does not appear there is any immediate need to implement compensating controls or workarounds at this time, but that assessment really depends on your own environment, security policy, and risk tolerance.

Skrillor 3y ago

We updated the FAQ question to cover this. For most users, fixing can be done by installing patched versions of their SSH implementations as they come available. If you feel uncomfortable waiting for an update, you may disable the affected cipher modes temporarily and use other modes like AES-GCM instead. But keep in mind that a faulty configuration can cause you to loose access to the server.

colmmacc 3y ago
Fwiw, I found a bunch of clients and libraries that didn't support AES-GCM at all, or only very recently. libssh2 is one example. That's made me nervous to make AES-GCM the only supported cipher as a mitigation.
- Aloisius 3y ago
  What about aes-ctr?
  - lambdafu 3y ago
    Depends a bit on the MAC. CTR-EtM is technically vulnerable (i.e. cryptographically broken), but due to key stream desynchronization the attack will quickly lead to application errors, defeating the attacker. See Sect. 4.3.3.
- shaicoleman 3y ago
  FYI: libssh2 supports AES-GCM since 1.11.0 (released 2023-05-30)