Whonix Wiki Download Docs News Support Tips Issues Contribute DONATE

[INVALID] Whonix KVM Security Bug Report - SPICE remote desktop protocol listening on all network interfaces

While following your advice and gutting KVM, QEMU, Whonix and Debian, I found a critical security mal-configuration affecting Whonix KVM

This security vulnerability allows complete take-over of Whonix Gateway and Workstation and is able to de-anonymize users with 0 interaction, and without their knowledge

How do I report this to you privately?

In short: gpg encrypted (nice but not mandatory) e-mail to me. I’ll forward to @HulaHoop who as far as I know didn’t publish a gpg public key.

Check your spam box

Received an forwarded to @HulaHoop.

Received a reply from @HulaHoop.

@anon12802191 you’re welcome to post this issue in public. @HulaHoop believes it can and should be discussed in public.

Note, if this is indeed an issue, it should be discussed with upstream too - since not only Whonix would be affected. This might apply:

If possible, please include practical steps, instructions to in your post on how to do that. A small demonstration. Textual only should be sufficient in this case but any format goes.

Here is the simplified steps needed to hack users of Whonix KVM outside of LAN:

  1. Download and setup masscan

  2. Scan the internet for ports 5901 and 5902. 5901 is usually Gateway and 5902 is Workstation

  3. Install virt-viewer package (available in all distros)

  4. You are now connected to them and can see their screen, control their mouse and keyboard and execute arbitrary commands

(Connecting to a spice server or session does not cancel other sessions, meaning the user is completely unaware someone connected and is watching them)

Additionally spice by default does not require authentication

As for de-anonymization, you already know their real IP from port scan and can tie it to Whonix

Here is the simplified steps needed to hack users of Whonix KVM inside of LAN:

  1. Download and install nmap (available in all distros)
  2. Port scan as previously mentioned
  3. virt-viewer, connect, tada!

To de-anonymoize you can use your own IP since it’s also their IP behind NAT. Incase of IPV6, you can still fetch their IP from inside NAT

Linux does not come with a firewall enabled by default (all major distros)

Spice is enabled by default in Whonix KVM XML configuration files

Now that I talked about how regular people can hack Whonix, let’s talk about the Government, ISPs and routers:

Goverments and ISPs can hack users this way, even if they have NAT + Firewall enabled! it is very easy actually
TR069 is “tech support” protocol built-in all routers and usually cannot be disabled at all. It is a backdoor.

Now that goverment can access the LAN, the Linux host is no longer protected by router NAT and firewall, they can do above steps to connect, spy, and de-anonymize

All of this can be solved by either disabling spice, or better yet, requiring a firewall setup step in the Wiki for Whonix KVM

I didn’t test this. Hopefully Whonix KVM maintainer @HulaHoop can test this soon.

Did you actually try from another computer in the LAN (or WAN if not using a NAT router / or with port forwarding) if this is possible?

Is this also a problem of other - non-Whonix - “normal” users of KVM + SPICE? If yes, is there any bug report? If not, why not?

Does running Whonix KVM as currently documented result in an open server port?

To check:

  1. Install Debian.

  2. Check open ports and write them to a file.

sudo netstat -tulpen > old

  1. Install packages required for Whonix KVM according to Whonix KVM documentation.

  2. Check open ports again and write them to a different file.

sudo netstat -tulpen > new

  1. Use any (graphical) diff viewer of your choice to compare the old and new file.

meld old new

  1. See the result.
  • If there are no changes, great, no new server port.
  • If there are changes, then let’s hope the ports are opened on localhost only. Otherwise that would be very bad.

If there is a SPICE server port listening on all interfaces and not only localhost, can the Whonix KVM xml files libvirt-dist/usr/share/libvirt-dist/xml at master · Kicksecure/libvirt-dist · GitHub be reconfigured to listen on localhost only? Perhaps even unix domain socket based?

NOTE: I am not a maintainer of Whonix KVM.

Can’t answer this because opsec, however all I can say is that it is indeed possible and spice is a remote-display system built for virtual environments which allows users to view a computing “desktop” environment – not only on its computer-server machine, but also from anywhere on the Internet

I would like to add that spice is support in Qemu and not KVM

I will do more testing like you advice, give me 24-48 hours to set up clean environments without harming my privacy

1 Like

@HulaHoop can you check if this is can be confirmed or not?

  • Duplicating steps.
  • Confirming with spice devs if possible (they have email and IRC channel).
  • Checking proxmox spice implementation how they do it as they have dedicated page for it.

otherwise this is going to be a big Q about KVM-Whonix anonymity.

Running netstat -tulpen shows related spice two related instances as and which I assume means that libvirt is only listening on the localhost,

A closer look at the VM settings shows that the defaults we ship with is:

<graphics type="spice" autoport="yes">
  <listen type="address"/>
  <clipboard copypaste="no"/>
  <filetransfer enable="no"/>
  <gl enable="no"/>

To have spice listen on all addresses you would have to go out of your way to configure it as so:

<graphics type="spice" autoport="yes" listen="">
  <listen type="address" address=""/>
  <image compression="off"/>
  <gl enable="no"/>

Additionally from the manual, you can completely disable listening forcing it to use file descriptors

<graphics type="spice">
  <listen type="none"/>
  <clipboard copypaste="no"/>
  <filetransfer enable="no"/>
  <gl enable="no"/>

I am not an expert on how spice is designed but I also assume the coders behind it were competent enough to spin up a separate instance for each VM so no cross VM snooping happens hence the two instances in netstat. I am also concluding they don’t open it up to connections form the whole world. An admin would explicitly select the TLS port and password for authentication to make this happen as documented.

Feel free to contact upstream at the libvir-users mailinglist and see what they have to say. Happy to be corrected if necessary and make the entire linux ecosystem safer in the process.

I recommend scanning the system using another machine as running the scanner on the same machine can give the illusion of it being impacted from a remote party while you were only getting false positives from scanning your whole system’s port ranges from the inside.


Thanks for sharing your expertise but I will still make my own tests from different machines to be sure :slight_smile:

I didn’t think of this, I will be sure to test this too

Unlikely to happen. User requested having their forum account to be deleted: