Net::Dropbear versions before 0.14 for Perl contains a vulnerable version of libtomcrypt.

Net::Dropbear versions before 0.14 includes versions of Dropbear 2019.78 or earlier. These include versions of libtomcrypt v1.18.1 or earlier, which is affected by CVE-2016-6129 and CVE-2018-12437.

A flaw was found in Dropbear. When running in multi-user mode and authenticating users, the dropbear ssh server does the socket forwardings requested by the remote client as root, only switching to the logged-in user upon spawning a shell or performing some operations like reading the user's files. With the recent ability of also using unix domain sockets as the forwarding destination any user able to log in via ssh can connect to any unix socket with the root's credentials, bypassing both file system restrictions and any SOPEERCRED / SOPASSCRED checks performed by the peer.

dbclient in Dropbear SSH before 2025.88 allows command injection via an untrusted hostname argument, because a shell is used.

A flaw was found in Dropbear. When running in multi-user mode and authenticating users, the dropbear ssh server does the socket forwardings requested by the remote client as root, only switching to the logged-in user upon spawning a shell or performing some operations like reading the user's files. With the recent ability of also using unix domain sockets as the forwarding destination any user able to log in via ssh can connect to any unix socket with the root's credentials, bypassing both file system restrictions and any SOPEERCRED / SOPASSCRED checks performed by the peer.

https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2025q2/002385.html announces the release of Dropbear SSH 2025.88 including this fix: - Security: Don't allow dbclient hostname arguments to be interpreted by the shell.

dbclient hostname arguments with a comma (for multihop) would be passed to the shell which could result in running arbitrary shell commands locally. That could be a security issue in situations where dbclient is passed untrusted hostname arguments.

Now the multihop command is executed directly, no shell is involved. Thanks to Marcin Nowak for the report, tracked as CVE-2025-47203 -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Hi!

On 2025-05-09 18:15, Alan Coopersmith wrote: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2025q2/002385.html announces the release of Dropbear SSH 2025.88 including this fix: - Security: Don't allow dbclient hostname arguments to be interpreted   by the shell.

dbclient hostname arguments with a comma (for multihop) would be   passed to the shell which could result in running arbitrary shell   commands locally. That could be a security issue in situations   where dbclient is passed untrusted hostname arguments.

Now the multihop command is executed directly, no shell is involved.   Thanks to Marcin Nowak for the report, tracked as CVE-2025-47203

I have two main questions:

Thanks in advance,

Albert

Hi Albert,

2024.86 is affected.

On 2025-05-13 2:47 am, Albert Veli wrote: I'm currently triaging CVE-2025-47203 to determine whether an embedded system we maintain is actually affected. It runs 2024.86, and is built with DROPBEARCLIPROXYCMD and DROPBEARCLIMULTIHOP enabled.

However, despite attempting various multihop hostname inputs containing shell metacharacters (e.g. semicolons, backticks, pipes, $(cmd)), I’ve been unable to trigger any shell execution or command injection. All such inputs are interpreted literally as hostnames.

I have two main questions:

1. Is there a reliable way to confirm from the command line whether I'm vulnerable? dbclient 'localhost,|touch 123 '

stdout is captured, stderr isn't. 2. Both dbclient and ssh are symlinks to the same dropbear binary. Does this CVE apply equally to both, or is it specific to dbclient? It applies to both.

Cheers, Matt

Thanks, this worked.

On 2025-05-13 02:47, Matt Johnston wrote: dbclient 'localhost,|touch 123 ' 2. Both dbclient and ssh are symlinks to the same dropbear binary. Does this CVE apply equally to both, or is it specific to dbclient? It applies to both.

You are probably already aware, but Cloudflare is throwing error 525 pages for Dropbear-related sites failing to establish connections to the origin servers:

https://matt.ucc.asn.au/dropbear/dropbear.html https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2025q2/002385.html

No need to follow up with me, just FYI.

Cheers, Dave Hart

On Tue, May 13, 2025 at 5:56 AM Matt Johnston <matt () ucc asn au> wrote: Hi Albert,

2024.86 is affected.

On 2025-05-13 2:47 am, Albert Veli wrote: I'm currently triaging CVE-2025-47203 to determine whether an embedded system we maintain is actually affected. It runs 2024.86, and is built with DROPBEARCLIPROXYCMD and DROPBEARCLIMULTIHOP enabled.

However, despite attempting various multihop hostname inputs containing shell metacharacters (e.g. semicolons, backticks, pipes, $(cmd)), I’ve been unable to trigger any shell execution or command injection. All such inputs are interpreted literally as hostnames.

I have two main questions:

1. Is there a reliable way to confirm from the command line whether I'm vulnerable? dbclient 'localhost,|touch 123 '

stdout is captured, stderr isn't. 2. Both dbclient and ssh are symlinks to the same dropbear binary. Does this CVE apply equally to both, or is it specific to dbclient? It applies to both.

Cheers, Matt

On 12/18/23 08:08, Fabian Bäumer wrote: Mitigations

Open source projects I see have implemented this already are:

- AsyncSSH 2.14.2: https://asyncssh.readthedocs.io/en/latest/changes.html#release-2-14-2-18-dec-2023

- Dropbear git: https://github.com/mkj/dropbear/commit/6e43be5c7b99dbee49dc72b6f989f29fdd7e9356

- Erlang ssh 5.1.1: https://www.erlang.org/doc/apps/ssh/notes

- golang.org/x/crypto 0.17.0: https://groups.google.com/g/golang-announce/c/qA3XtxvMUyg

- libssh 0.10.6 and 0.9.8: https://www.libssh.org/2023/12/18/libssh-0-10-6-and-libssh-0-9-8-security-releases/

- libssh2 git: https://github.com/libssh2/libssh2/issues/1290 https://github.com/libssh2/libssh2/pull/1291

- OpenSSH 9.6: https://www.openssh.com/txt/release-9.6

- Paramiko 3.4.0: https://www.paramiko.org/changelog.html#3.4.0

- PuTTY 0.80: https://lists.tartarus.org/pipermail/putty-announce/2023/000037.html

- russh 0.40.2: https://github.com/warp-tech/russh/releases/tag/v0.40.2

- SFTPGo 2.5.6: https://github.com/drakkan/sftpgo/releases/tag/v2.5.6

- ssh2 [node.js/npm] 1.15.0: https://github.com/mscdex/ssh2/commits/v1.15.0

- Tera Term 5.1: https://github.com/TeraTermProject/teraterm/releases/tag/v5.1

- Thrussh 0.35.1: https://pijul.org/posts/2023-12-18-thrussh-cve/

There's also some open bugs against these open source projects that are not yet handled:

- Apache Mina: https://github.com/apache/mina-sshd/issues/445

- ProFTPD (modsftp): https://github.com/proftpd/proftpd/issues/1760

- SSHJ: https://github.com/hierynomus/sshj/issues/916

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

On Tue, Dec 19, 2023 at 01:31:03PM -0800, Alan Coopersmith wrote: On 12/18/23 08:08, Fabian Bäumer wrote: Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Support for strict key exchange has been added to a variety of SSH implementations, including OpenSSH itself, PuTTY, libssh, and more.

Warning: To take effect, both the client and server must support this countermeasure. Open source projects I see have implemented this already are:

- AsyncSSH 2.14.2: https://asyncssh.readthedocs.io/en/latest/changes.html#release-2-14-2-18-dec-2023

- Dropbear git: https://github.com/mkj/dropbear/commit/6e43be5c7b99dbee49dc72b6f989f29fdd7e9356

- Erlang ssh 5.1.1: https://www.erlang.org/doc/apps/ssh/notes

- golang.org/x/crypto 0.17.0: https://groups.google.com/g/golang-announce/c/qA3XtxvMUyg

- libssh 0.10.6 and 0.9.8: https://www.libssh.org/2023/12/18/libssh-0-10-6-and-libssh-0-9-8-security-releases/

- libssh2 git: https://github.com/libssh2/libssh2/issues/1290 https://github.com/libssh2/libssh2/pull/1291

- OpenSSH 9.6: https://www.openssh.com/txt/release-9.6

- Paramiko 3.4.0: https://www.paramiko.org/changelog.html#3.4.0

- PuTTY 0.80: https://lists.tartarus.org/pipermail/putty-announce/2023/000037.html

- russh 0.40.2: https://github.com/warp-tech/russh/releases/tag/v0.40.2

- SFTPGo 2.5.6: https://github.com/drakkan/sftpgo/releases/tag/v2.5.6

- ssh2 [node.js/npm] 1.15.0: https://github.com/mscdex/ssh2/commits/v1.15.0

- Tera Term 5.1: https://github.com/TeraTermProject/teraterm/releases/tag/v5.1

- Thrussh 0.35.1: https://pijul.org/posts/2023-12-18-thrussh-cve/

There's also some open bugs against these open source projects that are not yet handled:

- Apache Mina: https://github.com/apache/mina-sshd/issues/445

- ProFTPD (modsftp): https://github.com/proftpd/proftpd/issues/1760

- SSHJ: https://github.com/hierynomus/sshj/issues/916 some more

Jsch (Java SSH): release 0.2.15 fixes it https://github.com/mwiede/jsch/releases/tag/jsch-0.2.15

Also apache-sshd and trilead-ssh2 as Java SSH implementations are affected.

tinyssh affected, has a ticket open.

rubygem-net-ssh also affected.

The rust ecosystem has a ssh crate which fixates its used libssh version. "libssh2-sys", so crates and binaries referencing will need updates.

python Twisted has an SSH stack too, but no chacha or etm macs so far.

Ciao, Marcus