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...

Yeah, I've commented on this one a few times. A modern cellphone is basically a combination of a microphone (and camera), software, and an internet connection. So if you're worried about corporate or government agencies spying on you, you really should be thinking twice about carrying around something that could quite easily be turned into a surveillance device...

no subject

While I don't think most people have to worry about the CIA monitoring them personally through their devices, you're missing some of the larger-picture points...

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

There's no obvious link to the Weeping Angel payload in the dump - it may or may not have leaked. But you're right that worrying about local compromises from the perspective of situations like abusive partners is a significant concern, and that's something we have to do something about. However, framing it as "THE CIA CAN SPY ON YOU" and not "Your TV makes it easy for someone to modify it to run arbitrary code and then report on your activity" doesn't help us here.

RCE through MPEG

For [2], a natural place to start looking for bugs would probably be HbbTv; most modern smart TVs accept an extra MPEG elementary stream with a URL that they go download and display as an overlay through some extra magic (so yes, anything you change channels, your TV tells the channel provider you just did that). This means you can run arbitrary JavaScript code in a probably-not-very-well-hardened browser directly on the TV.

no subject

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.

You would have thought that about AT&T/Verizon too, but they were happy to let the NSA into their datacenters for no real reason. Qwest's CEO didn't want to cooperate, and that 'earned' him an investigation from the SEC.

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

"An attacker can "turn off" your TV, reconfigure the internal speaker output as an input and listen to you on your "microphoneless" TV"

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

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

Given that:- 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.

I have a question about your GRUB2

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/sdaInstalling 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

Thanks for your comment, and I could manage to finally install your GRUB2 correctly. In configure, I set "--target=x86_64", and "--platform==efi". However, after I finally ran "grub-install" generated in the build directory and rebooted the system, I got a short boot error message saying "error: no symbol table" and then the system transited to my original bootloader's GRUB2. Here I booted Linux, and I see that hash values are measured upto PCR9, but PCR10~14 (kernel image) are all zero.

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

I reinstalled Ubuntu 16.10 (for MBR partition format compatible with BIOS and UEFI), and reinstalled your GRUB2. In particular, I ran ./configure, make, make install, and ./install-grub (but no update-grub) and there was no error. But if I reboots it, for some reason PCR 10~14 still contain only zeroes...

infecting a TV

The risk isn't that they will break into your house and reflash your TV. It's that they will intercept TVs in the sales channel and reflash them before they reach the final user. The intelligence agencies do this a lot. (http://www.theverge.com/2013/12/29/5253226/nsa-cia-fbi-laptop-usb-plant-spy)

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

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.

TV firmware updates

For what it is worth, my TV once received a firmware update without being connected to the Internet. It seems there is a facility to multiplex firmware updates into the DVB-T signal, and my TV notified me once it had finished receiving an update intended for that particular model.

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

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.