Close OpenSSH hole on 13.1-RELEASE server without shutting down?

[Brett Glass]

Hello!

We have a server running FreeBSD 13.1-RELEASE (curent patch level:
p5) in a remote location. It's running well, and uses a custom
statically linked kernel with no loadable modules to conserve
memory and allow better security.

We just found out about the latest OpenSSH bug, and want to patch.
Unfortunately, the freebsd-update utility isn't updating it,
because it is JUST ONE POINT VERSION beyond the earliest one for
which the Security Team has provided updates. And we can't shut the
server down to do a major upgrade right now. (Upgrades to systems
using custom kernels are especially dicey and frequently result in
lockouts, which in this case would not only interrupt important
activities but require a 50 mile drive.)

Any ideas as to how to JUST upgrade OpenSSH? I've looked at
installing the openssh-portable binary package, but when I start
the process by doing a "pkg update" I get a warning message
indicating OS mismatches for lots of packages. The error messages
all include the line

To ignore this error set IGNORE_OSVERSION=yes

(which I assume means to start sh, set that environment variable in
the shell, and then run the command). Is this safe?

--Brett Glass

[Dan Mahoney]

There is a workaround posted in the security advisory. You can also firewall off ssh connections from anywhere but trusted sources. Note that if you're still on 13.1 there are other security advisories to be aware of beyond the ssh one. (Albeit none quite so egregious).

-Dan

[Brett Glass]

At 07:03 PM 7/2/2024, Dan Mahoney wrote:

>There is a workaround posted in the security advisory.

Unfortunately, the "workaround" is in many ways as bad as the
vulnerability, because it exposes you to DoS attacks.

>You can also firewall off ssh connections from anywhere but trusted sources.

Yep. But if a worm based on this vulnerability begins to propagate,
it might get behind the firewall. We really want to patch.

--Brett

[Andrea Venturoli]

On 7/3/24 02:50, Brett Glass wrote:
> Hello!

Same question here, but for supported versions (13.3 and 14.x).

Is the following enough?

> cd /usr/src
> make buildworld
> cd /usr/src/secure/usr.sbin/sshd/
> make install
> cd /usr/src/secure/lib/libssh/
> make install
> service sshd restart

bye & Thanks
av.

P.S.
Out of mere curiosity:
_ all articles I read say that this is a vulnerability found in
OpenSSH’s server in *glibc-based* Linux systems;
_ I would desume that non-glibc-based systems are not vulnerable;
_ but FreeBSD is???

[Christos Chatzaras]

Here are the commands I used:

gitup release
cd /usr/src/secure/usr.sbin/sshd/
make all
make install
cd /usr/src/secure/lib/libssh/
make all
make install

Before running these commands, the date was "OpenSSH_9.6 FreeBSD-20240104," and after executing them, the date updated to "OpenSSH_9.6 FreeBSD-20240701."

To be certain, I plan to do a full rebuild today.

[lain.]

On 2024年07月03日 08:42, the silly Andrea Venturoli claimed to have said:
> P.S.
> Out of mere curiosity:
> _ all articles I read say that this is a vulnerability found in OpenSSH’s
> server in *glibc-based* Linux systems;
> _ I would desume that non-glibc-based systems are not vulnerable;
> _ but FreeBSD is???

For context, both glibc-based Linux distro's and FreeBSD, as well as
macOS and a number of NetBSD ports, are volunerable because the
SIGALRM handler calls syslog() function the exploit relies on.

OpenBSD and musl-based Linux distro's are not volunerable, because
OpenBSD uses syslog_r() instead, which they developed all the way back
in 2001.
And in the case of musl, its syslog implementation doesn't (sub)call
async-signal-unsafe functions, nor dynamically allocates memory.

--
lain.
PGP public key: https://fair.moe/lain.asc