Fuck it! I'm just downgrading to OpenSSH_8.4p1, which is supposedly unaffected. Because this newly patched OpenSSH_9.8p1 simply doesn't work on the only one of my systems that should be affected (32-bit, glibc).
It just crashes before any key exchange even starts — what's odd, it works when its binary isn't in /usr/local/sbin — it doesn't depend on whether the binary is stripped or anything else — it's just about the path, 9.1p1 and 8.4p1 built on the same system work, this one doesn't 🤬
And I don't want to investigate why this shit doesn't work so I'm just downgrading.
Can I have my old computing back please — without all this complexity? When vulnerabilities with such a severity happened once in a few years instead of every other month 😩
@vertka @romin
Nah, tried everything in the book — no success 🤷
It even works when I run binary from the build directory directly, which is extremely odd. This machine might have many… "peculiarities" as I build most stuff myself and it's not as clean as when software is installed with a package manager.
But I'm not motivated enough to investigate it further, besides, 8.4p1 built on the same machine with the same tools and with the same set of libraries works without a hitch — so why bother 😅
@vertka
It is! According to the paper, this CVE happened because important code, which in turn was a fix for similar prior vulnerability, was removed from one of the routines — hence its name: regreSSHion.
This machine was using 9.1p1 and I've downgraded to 8.4p1 instead of upgrading to 9.8p1 — because according to the paper versions above 4.4, but below 8.5p1 shouldn't be affected.
So in a way it's still a fix, just an unusual one 😄
>Can I have my old computing back please
no