Page MenuHomeVyOS Platform

Key reuse in VyOS Dropbear deployment
Open, HighPublicBUG

Description

Hi Daniil,

My name is Morgan Jones, software engineering lead for Viasat Secure Mobile.
I sent this to you over email, but have just been granted access to the VyOS bug tracker.

My work PGP key is: https://keys.openpgp.org/search?q=morgan.jones%40viasat.com

I have confirmed a vulnerability in the following VyOS version:

https://github.com/vyos/vyos-nightly-build/releases/tag/1.5-rolling-202503030030

  • Artifact: vyos-1.5-rolling-202503030030-generic-amd64.iso

This vulnerability exists in other versions of VyOS too; I have seen it on Sagitta 1.4 and Equuleus 1.3.
We will likely need to pull a CVE, though it is not triggerable by default as far as I know.
We probably should work with a 30 day disclosure window for this vulnerability.


Severity: High (likely)
Impact: All versions of VyOS installed using the same release ISO use the same Dropbear private keys,
resulting in the ability to man in the middle all SSH connections if Dropbear is enabled as the SSH daemon.

Reproducer after installing a system image:

[Host]

vyos@vyos:~$ config
vyos@vyos# set interface eth eth0 address dhcp
vyos@vyos# commit; save; exit
vyos@vyos:~$ sudo systemctl enable dropbear --now
vyos@vyos:~$ sudo dropbearkey -y -f /etc/dropbear/dropbear_ed25519_host_key
Public key portion is:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINRolGQ0jsTE2s6J/GwwzwaW1/E5jpOKCejeWKDcUCob root@vyos
Fingerprint: SHA256:jOukqk0yTJhPubLpTfxx0hK2ykyMEpYFm+ON6SpRYPA
vyos@vyos:~$ sudo sha256sum /etc/dropbear/*key*
409d342d3d96ca66ddcacddd58ae3e230ab5331bf170c0649d852b8ccd291b31  /etc/dropbear/dropbear_ecdsa_host_key
8c7ac47993e5f4714b6777967f8aa11ab7d11c5eb2d8d719ffc9490ad5f360ff  /etc/dropbear/dropbear_ed25519_host_key
c5da536e17ed3a9fe5405ff45822ae9c3b1f79fd93450592c004ae4f4ba76ca3  /etc/dropbear/dropbear_rsa_host_key

[Remote host]

$ ssh vyos@10.99.0.128
The authenticity of host '10.99.0.128 (10.99.0.128)' can't be established.
ED25519 key fingerprint is SHA256:jOukqk0yTJhPubLpTfxx0hK2ykyMEpYFm+ON6SpRYPA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.99.0.128' (ED25519) to the list of known hosts.
vyos@10.99.0.128's password:
Welcome to VyOS!

   ┌── ┐
   . VyOS 1.5-rolling-202503030030
   └ ──┘  current

 * Documentation:  https://docs.vyos.io/en/latest
 * Project news:   https://blog.vyos.io
 * Bug reports:    https://vyos.dev

You can change this banner using "set system login banner post-login" command.

VyOS is a free software distribution that includes multiple components,
you can check individual component licenses under /usr/share/doc/*/copyright
vyos@vyos:~$ exit

$ scp ~/Downloads/vyos-1.5-rolling-202503030030-generic-amd64.iso vyos@10.99.0.128:.
vyos@10.99.0.128's password:
vyos-1.5-rolling-202503030030-generic-amd64.iso                                       100%  549MB  51.4MB/s   00:10

$ ssh vyos@10.99.0.128
vyos@10.99.0.128's password:
vyos@vyos:~$ ls
vyos-1.5-rolling-202503030030-generic-amd64.iso
vyos@vyos:~$ sudo -s
vbash-4.1# mkdir /mnt/iso
vbash-4.1# mount -o loop vyos-1.5-rolling-202503030030-generic-amd64.iso /mnt/iso
mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
vbash-4.1# mount -o loop -t squashfs /mnt/iso/live/filesystem.squashfs /mnt
vbash-4.1# sha256sum /mnt/etc/dropbear/*key*
409d342d3d96ca66ddcacddd58ae3e230ab5331bf170c0649d852b8ccd291b31  /mnt/etc/dropbear/dropbear_ecdsa_host_key
8c7ac47993e5f4714b6777967f8aa11ab7d11c5eb2d8d719ffc9490ad5f360ff  /mnt/etc/dropbear/dropbear_ed25519_host_key
c5da536e17ed3a9fe5405ff45822ae9c3b1f79fd93450592c004ae4f4ba76ca3  /mnt/etc/dropbear/dropbear_rsa_host_key

Note that VyOS 1.3 also has a "dropbear-initramfs" folder with similar pregenerated keys in it.

We probably should figure out a way to mitigate this for new builds (i.e. by deleting the dropbear keys during image preparation)
and/or notify users that their dropbear keys aren't unique.

At least it's not OpenSSH, but I'd imagine running dropbear as the SSH daemon isn't unheard of. Does VyOS use dropbear for anything else?

Thanks,
Morgan Jones
<morgan.jones@viasat.com>

Details

Version
1.3, 1.4, 1.5
Is it a breaking change?
Perfectly compatible
Issue type
Security vulnerability

Event Timeline

mjones-vsat renamed this task from test to Key reuse in VyOS Dropbear deployment.
mjones-vsat changed the visibility from "Public (No Login Required)" to "Task Author".
mjones-vsat updated the task description. (Show Details)
mjones-vsat changed the visibility from "Task Author" to "Custom Policy".

Hi @dmbaturin,

Is there anyone else we should tag on this ticket?

Hi there,

Is there anyone we need to tag on this?

Looks like it was assigned too restrictively before.

FYI, @maintainers, VyOS dropbear host keys are not unique.

MITRE has assigned CVE-2025-30095.

[Suggested description] [17/27]> VyOS 1.3 through 1.5, when a release ISO through vyos-1.5-stream-2025-Q1-generic-amd64.iso is used, has the same
Dropbear private host keys across different customers' installations.
Thus, an attacker can conduct man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon
(not the default configuration). To mitigate this, one can
run "rm -f /etc/dropbear/*key*" and/or "rm -f
/etc/dropbear-initramfs/*key*" before using Dropbear as the SSH
daemon (this clears out all keys mistakenly built into the release image).


[VulnerabilityType Other]
CWE-798: Use of Hard-coded Credentials


[Vendor of Product]
VyOS


[Affected Product Code Base]
VyOS - 1.3, 1.4, 1.5


[Affected Component]
dropbear


[Attack Type]
Remote


[Impact Code execution]
true


[Impact Escalation of Privileges]
true


[Impact Information Disclosure]
true


[Attack Vectors]
Man in the middle of SSH connections made to a Dropbear server running on VyOS


[Reference]
https://vyos.dev/T7217
https://github.com/vyos/
https://vyos.net/get/stream/#1.5-2025-Q1

https://blog.vyos.io/vyos-stream-1.5-2025-q1

[Discoverer]
Morgan Jones, Viasat Secure Mobile

dmbaturin triaged this task as High priority.
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.

Hi Morgan,

Thanks for your report!

I see the CVE is only reserved so far, not yet published. This problem is not unique to VyOS as such, and may appear in a lot of Debian-based systems that are built with live-build and include Dropbear — I think it's worth reflecting in the CVE, so that other projects can pay attention to the issue.

The context is:

  1. VyOS uses Dropbear for its console server functionality. It's not enabled by default and we are not aware of anyone using it for system SSH (set service ssh is OpenSSH-based).
  1. The cause is that a) Debian's packaging is made to generate those keys in the post-install script (for the record, OpenSSH packaging has the same feature). b) live-build has a safeguard against that behavior in OpenSSH but no equivalent safeguard for Dropbear.

We now added the safeguard ourselves as a live-build hook, and made the configuration script generate keys if they don't exist. Current rolling release images and the upcoming 1.4.2 and 1.5-stream-2025-Q2 intentionally do not include host key migration on image update — to ensure that all updated systems start with freshly generated keys and never reuse the old, compromised ones.

I never tried to contribute to live-build, so I wonder if we can cooperate with some active Debian developers to add a safeguard to live-build.

dmbaturin changed the visibility from "Custom Policy" to "Public (No Login Required)".Tue, Mar 18, 6:14 PM

Thanks. I'll see what I can do about reporting this upstream!