Audio Retasking Risks

I have been giving much thought about the results of the paper:
SPEAKE(a)R: Turn Speakers to Microphones for Fun
and Profit

Summary:

  • All modern soundcards have restaskable jacks that can switch an output into input jack programitcally and vice versa.

  • Headphones work in the same way as microphones and can be turned into such.

  • Some speaker types like desktop loud speakers can also be turned into microphones - not that common.

  • This works when headphones are not actively transmitting audio.


My conclusion:

While virtual sound devices might be retaskable with software too (haven’t been able to successfully test that - more below) the malware still cannot access the soundcard settings of the host to retask it too given that the hypervisor is not broken. Headphones plugged into the host remain output only. Even if malware in the guest turns virtual soundcard output into input, its useless for the adversary if microphone/recording is muted on the host.

Besides documenting it there is no new dangers posed for VM users that need action.


Testing tools:

The hdajackretask tool part of the Debian -- Details of package alsa-tools-gui in sid suite is described by the paper as a way to retask jacks.

Updated readme found here:
http://git.alsa-project.org/?p=alsa-tools.git;a=blob;f=hdajackretask/README;hb=HEAD

Sound recording tools:
http://www.upubuntu.com/2013/05/how-to-record-your-voice-from.html

3 Likes

Got replies from the QEMU devs. They confirm my conclusion that no risk posed to host. Also virtual soundcards optionally have half-duplex modes that make audio input impossible.

https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04754.html
Replies:
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04899.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04906.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04904.html

1 Like

asked on for XEN / Qubes:
https://lists.xen.org/archives/html/xen-users/2016-12/msg00008.html