The Internet of Microphones
Mar. 7th, 2017 04:39 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59So the CIA has tools to snoop on you via your TV and your Echo is testifying in a murder case and yet people are still buying connected devices with microphones in and why are they doing that the world is on fire surely this is terrible?
You're right that the world is terrible, but this isn't really a contributing factor to it. There's a few reasons why. The first is that there's really not any indication that the CIA and MI5 ever turned this into an actual deployable exploit. The development reports[1] describe a project that still didn't know what would happen to their exploit over firmware updates and a "fake off" mode that left a lit LED which wouldn't be there if the TV were actually off, so there's a potential for failed updates and people noticing that there's something wrong. It's certainly possible that development continued and it was turned into a polished and usable exploit, but it really just comes across as a bunch of nerds wanting to show off a neat demo.
But let's say it did get to the stage of being deployable - there's still not a great deal to worry about. No remote infection mechanism is described, so they'd need to do it locally. If someone is in a position to reflash your TV without you noticing, they're also in a position to, uh, just leave an internet connected microphone of their own. So how would they infect you remotely? TVs don't actually consume a huge amount of untrusted content from arbitrary sources[2], so that's much harder than it sounds and probably not worth it because:
YOU ARE CARRYING AN INTERNET CONNECTED MICROPHONE THAT CONSUMES VAST QUANTITIES OF UNTRUSTED CONTENT FROM ARBITRARY SOURCES
Seriously your phone is like eleven billion times easier to infect than your TV is and you carry it everywhere. If the CIA want to spy on you, they'll do it via your phone. If you're paranoid enough to take the battery out of your phone before certain conversations, don't have those conversations in front of a TV with a microphone in it. But, uh, it's actually worse than that.
These days audio hardware usually consists of a very generic codec containing a bunch of digital→analogue converters, some analogue→digital converters and a bunch of io pins that can basically be wired up in arbitrary ways. Hardcoding the roles of these pins makes board layout more annoying and some people want more inputs than outputs and some people vice versa, so it's not uncommon for it to be possible to reconfigure an input as an output or vice versa. From software.
Anyone who's ever plugged a microphone into a speaker jack probably knows where I'm going with this. An attacker can "turn off" your TV, reconfigure the internal speaker output as an input and listen to you on your "microphoneless" TV. Have a nice day, and stop telling people that putting glue in their laptop microphone is any use unless you're telling them to disconnect the internal speakers as well.
If you're in a situation where you have to worry about an intelligence agency monitoring you, your TV is the least of your concerns - any device with speakers is just as bad. So what about Alexa? The summary here is, again, it's probably easier and more practical to just break your phone - it's probably near you whenever you're using an Echo anyway, and they also get to record you the rest of the time. The Echo platform is very restricted in terms of where it gets data[3], so it'd be incredibly hard to compromise without Amazon's cooperation. Amazon's not going to give their cooperation unless someone turns up with a warrant, and then we're back to you already being screwed enough that you should have got rid of all your electronics way earlier in this process. There are reasons to be worried about always listening devices, but intelligence agencies monitoring you shouldn't generally be one of them.
tl;dr: The CIA probably isn't listening to you through your TV, and if they are then you're almost certainly going to have a bad time anyway.
[1] Which I have obviously not read
[2] I look forward to the first person demonstrating code execution through malformed MPEG over terrestrial broadcast TV
[3] You'd need a vulnerability in its compressed audio codecs, and you'd need to convince the target to install a skill that played content from your servers
You're right that the world is terrible, but this isn't really a contributing factor to it. There's a few reasons why. The first is that there's really not any indication that the CIA and MI5 ever turned this into an actual deployable exploit. The development reports[1] describe a project that still didn't know what would happen to their exploit over firmware updates and a "fake off" mode that left a lit LED which wouldn't be there if the TV were actually off, so there's a potential for failed updates and people noticing that there's something wrong. It's certainly possible that development continued and it was turned into a polished and usable exploit, but it really just comes across as a bunch of nerds wanting to show off a neat demo.
But let's say it did get to the stage of being deployable - there's still not a great deal to worry about. No remote infection mechanism is described, so they'd need to do it locally. If someone is in a position to reflash your TV without you noticing, they're also in a position to, uh, just leave an internet connected microphone of their own. So how would they infect you remotely? TVs don't actually consume a huge amount of untrusted content from arbitrary sources[2], so that's much harder than it sounds and probably not worth it because:
YOU ARE CARRYING AN INTERNET CONNECTED MICROPHONE THAT CONSUMES VAST QUANTITIES OF UNTRUSTED CONTENT FROM ARBITRARY SOURCES
Seriously your phone is like eleven billion times easier to infect than your TV is and you carry it everywhere. If the CIA want to spy on you, they'll do it via your phone. If you're paranoid enough to take the battery out of your phone before certain conversations, don't have those conversations in front of a TV with a microphone in it. But, uh, it's actually worse than that.
These days audio hardware usually consists of a very generic codec containing a bunch of digital→analogue converters, some analogue→digital converters and a bunch of io pins that can basically be wired up in arbitrary ways. Hardcoding the roles of these pins makes board layout more annoying and some people want more inputs than outputs and some people vice versa, so it's not uncommon for it to be possible to reconfigure an input as an output or vice versa. From software.
Anyone who's ever plugged a microphone into a speaker jack probably knows where I'm going with this. An attacker can "turn off" your TV, reconfigure the internal speaker output as an input and listen to you on your "microphoneless" TV. Have a nice day, and stop telling people that putting glue in their laptop microphone is any use unless you're telling them to disconnect the internal speakers as well.
If you're in a situation where you have to worry about an intelligence agency monitoring you, your TV is the least of your concerns - any device with speakers is just as bad. So what about Alexa? The summary here is, again, it's probably easier and more practical to just break your phone - it's probably near you whenever you're using an Echo anyway, and they also get to record you the rest of the time. The Echo platform is very restricted in terms of where it gets data[3], so it'd be incredibly hard to compromise without Amazon's cooperation. Amazon's not going to give their cooperation unless someone turns up with a warrant, and then we're back to you already being screwed enough that you should have got rid of all your electronics way earlier in this process. There are reasons to be worried about always listening devices, but intelligence agencies monitoring you shouldn't generally be one of them.
tl;dr: The CIA probably isn't listening to you through your TV, and if they are then you're almost certainly going to have a bad time anyway.
[1] Which I have obviously not read
[2] I look forward to the first person demonstrating code execution through malformed MPEG over terrestrial broadcast TV
[3] You'd need a vulnerability in its compressed audio codecs, and you'd need to convince the target to install a skill that played content from your servers
Said it before...
Date: 2017-03-08 02:12 am (UTC)no subject
Date: 2017-03-08 07:32 am (UTC)The CIA tools are available widely, not just to the CIA, because they lost control of them. Even if the CIA isn't targeting you specifically, what about other people who have control of these systems? What about a stalker that uses these tools to pwn the device of their stalkee?
The other point I want to touch on: If these tools have leaked, what else has leaked and to who? The biggest danger of mass information collection of citizens by the US Government might not be the US Government, but whichever hacking group/nation gets access to that data first.
no subject
Date: 2017-03-08 07:52 am (UTC)RCE through MPEG
Date: 2017-03-08 01:00 pm (UTC)/* Steinar */
Re: RCE through MPEG
Date: 2017-05-02 03:28 pm (UTC)no subject
Date: 2017-03-08 02:10 pm (UTC)I'm certainly not suggesting Amazon is cooperating with any intelligence agencies, but don't make the assumption that they'll prioritize your interests over the USG's.
Disappointed in stark contrast between this post and normally high quality of other posts
Date: 2017-03-08 04:50 pm (UTC)Are you actually serious? I don't want to sink to your level of oversimplification, but on very loose terms, generally, a speaker will be driven by an amp, which will in turn be driven by a DAC, i.e. a piece of silicon that makes analogue signals out of bits.
By contrast, a microphone will be feeding an ADC - something that makes bits out of analogue signals. It's pretty much the opposite of the bidirectional data flow you are implying is possible. Sure it might be part of a bigger SoC but it will still be incapable of driving a speaker for sure.
I don't understand what could motivate someone to make this point, other a complete lack of understanding of basic electronic engineering. Look at a phone schematic. Show me some code for an Android phone that allows the speaker to be used a mic. I have respect for you as an author, but this point is stupid, no other way to describe it.
Lastly, even if your absurd point was valid, and it was possible to just start using a speaker as a mic arbitrarily, have you ever tried using a speaker as a mic, sure, it might "work" but the speaker will have very unfavourable audio characteristics when used as a mic, and you will capture sound, but getting meaningful information out of it, e.g. a conversation, is a very different problem, one which you won't be able to solve due to physical limitations of the device.
TLDR: prove that there exist a significant number of devices where the speaker can be reconfigured to act as a mic in practise or GTFO
Re: Disappointed in stark contrast between this post and normally high quality of other posts
Date: 2017-03-08 05:20 pm (UTC)http://in.bgu.ac.il/en/Pages/news/eaves_dropping.aspx
Re: Disappointed in stark contrast between this post and normally high quality of other posts
Date: 2017-03-11 06:36 pm (UTC)Active Loudspeakers vs. Passive Loudspeakers
Note, however, that the reversibility principle poses a limitation: the speaker must be passive (unpowered), without amplifier transitions. In the case of an active (self-powered) speaker, there is an amplifier between the jack and the speaker, hence the signal won't be passed from the output to the input side [6]. Since most modern loudspeakers have an internal amplifier [7], the threat presented in this paper is primarily relevant to headphones and earphones, and not to the loudspeakers typically connected to a PC.
______________
So... laptop speakers may be less of a threat than your earpods. Still... (Makes me glad my headphones are active-amplified Bose w/ no passthrough.)
Re: Disappointed in stark contrast between this post and normally high quality of other posts
Date: 2017-03-12 10:46 pm (UTC)- In smartphones and many device using SOC[1], Many of the CODECs[2] used can indeed configure the functions of pins trough software. This is typically done by the Linux kernel.
- In laptops there are microphones too, and the pins can also be reconfigured. This is often called "retasking" for Intel "sound cards".
- Desktop computers falls into the same categories than laptops but have no microphone
Assuming that the user removed all internal microphones of the given device (smartphone or laptop) or has a desktop computer, how is the above relevant?
If we assume that the CODEC or sound card has no special constraint with routing the pins to the function[3], we then can easily test it.
To do that you can either:
- Connect your headphones to the microphone jack and test how much sound level you can record.
- Try to reroute pins, a retasking GUI exists for intel HDA sound cards and try to record.
The issue is then that the volume of the sound you recorded is not the same with headphones than a microphone because of physical constraints: The microphone is physically designed to get sounds transformed as electricity. If the speaker require a lot of power to operate, then you would need in return to shout very loudly to make the membrane vibrate enough to produce electricity...
The question is then how much usable is the recording. Do algorithm exist to isolate voice in that context? Will they exist tomorrow?
[1] System on a chip, the "Processor" of your phone.
[2] A CODEC is the analog part of the "sound card". It is typically connected to the SOC trough PCM.
[3] You will need to check the relevant datasheets to find out.
HeckTor
I have a question about your GRUB2
Date: 2017-03-09 05:40 am (UTC)I've been looking for a bootloader supporting TPM 2.0 for 6 months, and I finally ended up with your GRUB2. I believe your patched GRUB2 supports UEFI TPM 2.0, right? I tried to install it, but I get the error as follows:
sudo ./grub-install --directory=../lib/grub/x86_64-efi/ /dev/sda
Installing for i386-pc platform.
./grub-install: warning: cannot open directory `/home/skyer/Desktop/grub/build/share/locale': No such file or directory.
./grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
./grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
./grub-install: error: will not proceed with blocklists.
Is this because your GRUB2 supports only BIOS partitions (not UEFI)? If so, if I format my SSD into BIOS partition and re-install Ubuntu, would I be able to use your GRUB2 to use TPM 2.0?
Sorry for this sudden question, but it's because I desperately need to use TPM 2.0 when booting up...
Re: I have a question about your GRUB2
Date: 2017-03-09 05:24 pm (UTC)You've configured and built a BIOS version of grub, you need to pass the correct arguments to configure to tell it to do a UEFI build:
./configure --with-platform=efi
Re: I have a question about your GRUB2
Date: 2017-03-09 09:32 pm (UTC)So in terminal, I ran "update-grub" which was the binary from my old GRUB2, and now kernel completely panicks. I think it's because I should have run your new GRUB's "update-grub" binary, but I couldn't find any newly generated "update-grub" in the build directory.
Would "error: no symbol table" be a cause of PCR10~!4 not being measured? Or should I run a newly generated "update-grub" by your code? (but I can't find this binary)
Re: I have a question about your GRUB2
Date: 2017-03-11 04:11 am (UTC)infecting a TV
Date: 2017-03-13 09:26 pm (UTC)Decades ago, I talked to an old spook about a program to modify the firmware in printers on their way to Russia. This was back when Appletalk was state-of-the-art networking; the printer secretly doubled as a client to file servers. I don't know how the data were exfiltrated.
TPM2-GRUB2 resolved
Date: 2017-03-20 07:03 am (UTC)Today I looked into your GRUB2-TPM2 source code and finally realized it's actually working, but extends the kernel image and initrd into PCR 9, instead of PCR 10~14. In your blog article, you said these values will be extended to PCR 10~14, which is different from your actual implementation.
Here I manually created grub_printf() logs of all PCR extension events occuring upon booting.
GRUB2 TPM2 Screenshot: http://bigmail.mail.daum.net/Mail-bin/bigfile_down?uid=3CTYs-xo5EfJy9-Ui8oDlgp-zJRm9skt
[execute.c] log is for extending GRUB2's executed commands.
[dl.c] log is for extending .mod module files loaded.
[i386/linux.c] log is for extending Linux kernel file loaded.
[linux.c] log is for extending Initrd RAM disk loaded.
For log parameters,
- version: TPM version (1.2 or 2)
- size: file size (bytes)
- pcr: PCR register number (8 is for extending human-readable ASCII values, 9 is for extending bynary files)
- description: the target to be extended (either GRUB2 commands or module/kernel/ramdisk filenames)
TV firmware updates
Date: 2017-03-24 05:24 am (UTC)It's not clear how useful this would be for espionage, since it would be difficult to target, require cooperation of the broadcaster, and required user interaction to apply the update.
Related piece from On The Media
Date: 2017-03-31 05:38 am (UTC)https://www.wnyc.org/story/what-media-got-wrong-about-latest-wikileaks-dump/
mjg59, I mentioned this to you at libreplanet, and also how I highly recommend this podcast in general. It's not a tech podcast, and it's by 2 old non-tech people, but sometimes it does a surprisingly good job on tech, and generally never eye rollingly bad like most media.