Does openwrt vulnerable due to openssh

new openssh vulnerability arrived does it effects openwrt https://www.openssh.com/releasenotes.html
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

1 Like

does it affect dropbear too, it's the default sshd in openwrt ?

2 Likes

You have to try hard (read: own custom build with multiple non-default packages) to achive vulnerable software combo, namely both of:

  • replace musl to glibc in build
  • replace dropbear ssh server for openssh ssh server
2 Likes

This vulnerability is exploitable remotely on glibc-based Linux systems,
where syslog() itself calls async-signal-unsafe functions

OpenWrt uses musl, not glibc, to provide the C standard library. According to the musl folks, its syslog() implementation isn't exploitable in this manner:

Also, this has already been fixed in upstream OpenSSH as part of a major code refactor:

On June 6, 2024, this signal handler race condition was fixed by commit
81c1099 ("Add a facility to sshd(8) to penalise particular problematic
client behaviours"), which moved the async-signal-unsafe code from
sshd's SIGALRM handler to sshd's listener process, where it can be
handled synchronously:

https://github.com/openssh/openssh-portable/commit/81c1099d22b81ebfd20a334ce986c4f753b0db29

This is notable because this particular bug was fixed in 2006 (!) but was accidentally reintroduced again in 2020 by a missing #ifdef. Refactoring the signal handling code would prevent this from appearing again.

6 Likes

should we switch to wolfssh https://github.com/wolfSSL/wolfssh

you're not really reading/understanding the replies you're getting, are you ?

6 Likes

no i didnot read anything just post what i find a better alternative

how can you tell what alternatives there are (or if any are required) if you don't read the replies ?

6 Likes

You should try reading the replies, it's really helpful. I spent time thoroughly reading the two links you've provided in your original post, so I would appreciate it if that same courtesy was reciprocated.

Please elaborate. In case you weren't already aware, the default SSH server in OpenWrt is Dropbear, not OpenSSH. So be sure to consider Dropbear when comparing with wolfSSH in the analysis.

8 Likes

No it doesn't.

:laughing: TL;DR

Hopefully that helps.

As a courtesy in the future, you might wanna read if you're asking others to read.

10 Likes

@openrouterman - 9.8p1 was just merged, FYI: https://github.com/openwrt/packages/commit/75674f0439ee497bc6b77222a23e3974d150be89

4 Likes

Noting that actual forks building glibc and openssh by default, like for relatively big systems, and those are out if scope of OpenWRT patch and will take some time to catch up.

Just heard it takes 10k of tries in over 4 hrs on a Debian system that has glibc & openssh installed. For older systems with a 10m connection timeout it takes about a week.

This does not affect OpenWRT as noted in the thread, however exploits were getting stacked in the past to get remote code execution. There is always the possibility this flaw could be part of a future exploit.

Openwrt dropbear and musl is not vulnerable. You can run exploits for months filling logs.

1 Like

It's also, at the moment, only affecting 32 bit systems (i386 specifically). It may affect amd64/x64, but nobody has made that work yet.

I'd give it time. Qualys says modern Debian is vulnerable but hasn't released the how-to yet. OpenWRT in stock config is safe, but as mentioned if you replace your SSH stack with OpenSSH it obviously can be attacked if you have the right glibc version. I was worried but I'm safe. Phew.

1 Like

it's look danger.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.