Schneier on Security

Nick P • June 14, 2014 11:20 AM

re badBIOS’s style audio channels

It should’ve been considered earlier as audio was a well-known covert channel. I did a search going way back. The use of audio for covert signaling existed in the 90’s and in patents no later than 2000. The use case was typically watermarking. However, if you can embed a watermark you necessarily have a covert communication channel. Perhaps the industry needs to include that concept into our formal investigations for covert channels. Such a criteria might have gotten it (and others) noticed well before the badBIOS debate.

So, the covert acoustical mesh networks aren’t a “new” attack vector. They’re a new construction built on an old, known covert channel that security researchers simply didn’t pay attention to. Hence, the value of a more encompassing framework for identifying such things.

That said, I still think Kemmerer’s Shared Resource Matrix is fine and that people just ignored hardware/peripherals during analysis.

Nick P • June 14, 2014 1:07 PM

@ Wael

“The thing that is being questioned is how can a pristine out of the box computer have the ability to receive sound packets, decode them and store them in persistent memory if the target laptop doesn’t have this functionality already in? ”

Audio controllers and drivers have such functionality built-in anyway, don’t they? I’m admittedly just guessing as I’ve never built them.

“And if the functionality is not already built-in the target laptop, what is the attack vector used to create this functionality?”

IIRC, most of the claims were that the PC was attacked somehow and the audio was used for C&C. And then there were other discussions/claims of audio attacks. The NSA TAO catalog has USB implants that hit the BIOS for persistence, while providing built-in radio for C&C. So, that part is explainable easy enough: some kind of privileged access (kernel or DMA) is used to either inject code into a running BIOS or insert a malicious BIOS. The BIOS is usually used to initiate reinfection so it’s the root of mistrust. They had similar attacks on hardware firmware and on wifi. So many 0-days in so many potentially exposed places that there wasn’t even a need to attack via audio.

That said, if they did attack the system that way I’d look into the microcontroller and drivers. At some level a routine will interpret incoming data. These routines are probably tightly coded and privileged. There are certainly vulnerabilities in there. So, one might be able to craft audio data that gets through any initial signal processing, hits a weakspot, and causes execution of malicious code. Then, there’s always the subversion risk as RobertT pointed out that most components in the market are an oligopoly and most audio controllers are blackboxes made by one vendor (RealTek?).

All in all, it’s just stuff that IOMMU’s and a POLA architecture probably would’ve prevented automatically without us even worrying about the vector past hacker-induced audio playback problems (eg injecting death metal into Beethoven).

Nick P • June 15, 2014 9:25 AM

@ koita

Wifi blocking wallpaper and paint are old news:

http://www.pcmag.com/article2/0,2817,2404219,00.asp

NIck P • June 15, 2014 9:50 AM

@ Wael

“1- They are not always on, receiving packets, discarding uninteresting ones, and handling packets that are addressed to them.”

Mine is on shortly after boot. There’s something waiting for a mic to be plugged in. There’s an audio stack already loaded. There is a boot-up sound that uses it.

“2- They need an application to communicate with the device driver and send it commands to do things — either openfile(), readfile(), createfile(), or any of the other IOCTLS implemented by the driver.”

The microphone needs an app to communicate with it to receive something? I thought you needed a mic for audio communications between unmodified nodes. That’s the part of the stack I’d think injection would happen externally.

“It is a requirement of the target system to be ready for a remote acoustic command to start doing its thing. If that is the case, then subversion is a probability. ”

Or it’s just been hit by another exploit. They chain them together. The combo is typically (1) get privileged access, (2) implant BIOS or some firmware for persistence, and (3) enable covert C&C between nodes or master/slave.

“As far as I know for any application to write any persistent data to the BIOS, the BIOS must export such an interface. On most systems I worked on, the BIOS flashes itself when you update your BIOS. And the BIOS usually verifies digital signatures or at the very least some checksums before accepting to flash an image.”

Membromi (2012) flashed Award BIOS’s as part of its operation. Others might be subverted in that NSA gets components signed without questions asked. There were only a few BIOS’s before UEFI. And a few of us here have suspected UEFI is partly to make it easier on groups like NSA. Could explain a certain amount of secrecy around its operation that existed a while back. Not sure if that’s still the case.

“The problem with badBIOS claims is the attack channel is no longer a piece of software smashing the driver stack! It’s an acoustic packet, see. An acoustic packet that’s causing a buffer overflow on a device driver thats not even accepting commands from an application. ”

See microphone stack issue above. If your argument still applies to it, then yes this would be a problem.

“So UEFI needs to be looked at as a possible culprit.”

Yep. Clive and I haven’t trusted it since they started building it. It’s guilty until proven innocent far as we’re concerned. 😉

Nick P • June 15, 2014 4:18 PM

@ Wael

“Explain to me how a pristine system is infected with acoustic waves.”

“I wanted to understand how a sound wave can cause a weakness and exploit it, then install a piece of code that accomplishes the deed – all through sound.”

You’re really hung up on the fact that the original source is a sound wave. Let’s rephrase that a bit:

“…is infected with electrical signals traveling over copper.”

“…all through electricity.”

“…is infected with photons traveling down an optical fiber.”

“…all through light.”

“…is infected with electromagnetic waves flowing through a home.”

“…all through radio”

So, assuming your computer doesn’t use sound in native form, let’s restructure it a bit: sound wave -> 1’s and 0’s -> microcontroller firmware -> driver -> potential kernel functions -> potential user-mode application. The sound wave part is indeed pretty harmless, much like the light on fibers of my Ethernet. The microcontroller firmware, driver, and kernel, on the other hand, have privileged software that interprets 1’s and 0’s. Incorrect interpretations can lead to malicious code executing. Now, I’m not educated enough on internals of how this is handled on sound cards to say if they’re at risk of this. However, it’s been a problem on almost every other device.

So, I’d have to eliminate the possibility of a software vulnerability interfaced to a mic before I’d think it was impossible. I’d also look at any codec’s or other software that transform the newly digitized audio. There’s likely stacks, buffers, and so on in there. So, there’s potential for attack. Just not sure how much.

I do think the majority of audio networking use is for covert channels of already compromised systems, though. Early badBIOS dicussions, academic work, and TAO catalog all support this.

Nick P • June 15, 2014 4:55 PM

@ Mike the goat

re x86

I agree far as secure architectures goes. However, getting rid of it is unlikely to happen. There’s SO MUCH legacy software on it (i.e. Windows). Remember that Intel tried repeatedly with i432 APX, i960, and finally Itanium. Itanium was a nice combo of Intel and HP PA-RISC expertise. It was their best chance due to its speed, RAS features, easy compiler development, and many built-in security features. It’s roadmap indicates it’s about to be buried due to almost no market acceptance outside SGI (bankrupted) and HP enterprise servers. The lesson goes back to Orange Book B3/A1 systems including a painful UNIX compatibility layer: the legacy software must be preserved somehow if wide market is to buy it.

Note: DEC and IBM both used binary translation tech to solve some of these problems in the past. Not sure if that will work today. Loongson is trying for x86.

Now for the fun part: building new systems. These we can throw x86 out. So, you want simple and RISCy. The DARPA CRASH processor designs I’ve referenced meet that requirement. VAMP and AAMP7G do given they’ve been formally verified for correctness, the latter for separation too. That Intel bought Alpha means it will likely stay dead unless revived by open core effort. SPARC isn’t dead as it’s getting continued investment by Oracle, Fujitsu, and others. There are also two versions of it opened up and a consortium to license the architecture for redevelopment. IBM recently created an organization to do something similar with POWER architecture. It’s not being opened, though.

I’m not a fan of ARM besides its chip efficiency and price. Funny that you say MIPS is low end as my first exposure to it was SGI Octane workstation and Onyx2 servers. For something modern, maybe specs on Cavium’s Octeon III will change your mind. There’s also possibility of cheaply licensing something that’s nearly dead and getting owners less all the time. Intel’s i960, HP’s PA-RISC, Renasas’s Super-H, or even Alpha might be available. (Itanium given time haha) There’s also free, open cores such as OpenRISC.

“In short – there is a trust deficit and I am not sure how the hell it will be fixed.”

If legacy compatibility is maintained, I’m not sure it can be. If clean slate, I have methods to fix it all the way to the hardware. That’s when limited expertise and small number of chipmakers cause risk to mount. Yet, getting to that part knocks out vast majority of risk and attackers. It’s why I’m mostly focusing on that aspect of the journey.

Nick P • June 15, 2014 5:20 PM

@ Mike

I was trying to figure out who owns the I.P. for Alpha processors. Apparently, Intel just took over Compaq’s business and it’s Samsung that has the processor. They were manufacturing it for a while. This article says they and Compaq invested $500 million to get it where it was. They got essentially no return so coffin was closed on it. So, it’s doubtful they’d do anything but license existing work given what was already lost on it. And that gives an idea of what a cutting edge chip with custom circuits can cost. Ouch.

@ Wael

That’s one vector. Like I said, I no nothing of how soundcards and drivers actually process the digitized audio data. There’s plenty to explore in there. Just look for common issues in buffers, stacks, DMA handling, and so on. There might be something, might be nothing. (shrugs) Still think it had nice subversion potential due to both few vendors and the fact that few worry about such chips. The s

Nick P • June 16, 2014 11:21 AM

@ Clive Robinson

It’s interesting, but different than what we discuss. We are talking about code injection via wireless capabilities. This is an eavesdropping technique that uses emanation attacks. They get that application on a mobile phone by infecting the phone with a virus through a spearfishing SMS message prompting a download. Old EMSEC advice of EM shielding and banning cell phones would defeat this attack. As we’ve discussed, this advice is rarely followed or known in most organizations. So, it’s quite a nice attack vector.

re Elovici

Seems to be a smart guy. Most of his work is on anonymity schemes and identifying malware. That those people know EMSEC enough to mount an attack also speaks well for them. Of course, Israel is one of the top nations in both human and electronic spying capabilities. I’d expect no less from a “well-connected” Comp Sci professor over there. 😉

@ 65535

I guarantee you Target’s INFOSEC isn’t that good. Malicious insiders (or contractors) would be an easy possibility. I can only speculate on PF Chang’s that they probably don’t do much better. However, one commenter on Kreb’s mentioned that their response to switch to the manual method happened very quickly. The commenter said it implied a backup plan and speedy implementation of it. That might indicate whoever is handing such stuff is at least doing what due diligence they can within the organization.

Re acoustic method. NSA has many methods. They have radio tech embedded in some of their implants for C&C networks. They might have acoustic, too. That the recent academic papers describe such things mean we must assume NSA’s engineers went ahead and built it too. It’s not hard at all compared to much of what’s in the TAO catalog. Of course, like I told Wael, it’s not as big a threat if you have an IOMMU isolating it from rest of system memory. And if your architecture is POLA-enforcing in general (eg microkernel).

@ Mike the Goat

The emulator approach was what I was hinting at. Transmeta did it with Crusoe, Loongson does it with custom x86-on-MIPS instructions, and one can argue VIA does it [very well] in microcode. VIA always impressed me for hanging in the x86 market so long despite tiny market share. The Loongson processor is exactly what it looks like: China’s own processor to complement their own OS and software stacks. They figure they can trust something most if they build it themselves. There’s also I.P. and national pride benefits. Look at this Wikipedia article to see the specs of each release. It’s quite amazing how much they improve each one seeing as they have less experience than the competition.

re trust

The EAL6-7 development processes give an idea of how much one must worry about to make something work with malicious developers. The simplification of it is to have many parties with knowledge of domain, a mutual suspicion encouring strong review, a duplication of tools like SCM to spot to aid integrity, and a ‘design for verification’ philosophy for each component of the system. This can work on hardware HDL, microcode, firmware, and software. There’s also vettable tools, either open or academic, that can synethize some HDL’s.

Discussions with RobertT show the fabbing aspects of this aren’t worth exploring, though. The whole process is a black box full of exotic, ever-changing technology and people of unknown trustworthiness. With the amount of custom, esoteric work going into each project, the reviewers wouldn’t even know what a subversion was if they were staring at it. RobertT said that, for this reason, having outsiders secure the fabbing process is laughable. That he figured the design itself, or fabbers design database, is the best target is reason enough to focus most efforts there.

So, looking at our insider’s advice, I tried to mentally narrow things down to figure out what most critical part of process was. I decided the production, transportation, and application of the masks is it. Those turn the materials into the circuits. RobertT said mask production is usually outsourced by fab. It’s also as esoteric as the rest. So, my potential solution is to get a collaboration (public/private) to fund a secure mask making organization and process for a process node that will be useful for a while. They can license the tech, under thorough review by experts, from an existing mask maker maybe with incentive of giving generous royalties per device produced. The people and location are carefully picked for combination of brains and trustworthiness. The process is quite open to inspection. Company would partner with a fab to provide basic security measures to ensure proper masks are used. (There’s more but I’m summarizing key points here.)

Sound like a hell of a lot of work that leads to problems in market competitiveness? Yep. That’s why I’m minimizing my mental effort on that problem and working on the others. Not sure economics will let us secure the chip production process. It’s also the best target for a very capable TLA given constant consolidation.

“That’s a hell of a figure. It makes me dispair to think that only an established player or a company with state backing (China cough) would have the cash to actually make what we’re discussing happen. Which is why we are stuck with the abysmal situation we’re in at the moment.”

The full process, yes. If we trust the production, then the chip design and ASIC’s can be made for a few million if done right. Adapteva proved that with their Epiphany line’s development.

Nick P • June 17, 2014 10:47 AM

@ Clive Robinson

re EM injection

Yeah, I misread that part of the article. My bad. Your two possible explanations of FUD or subversion are good. If there’s no subversion, then there is still a technical possibility. Remember the active EMSEC attack on the RNG that weakened it? I wonder if blasting some EM waves at a system can have any other effects on its internal state. Effects that allow some kind of code injection, probably via a different vector. This might especially be true if the machine supports some kind of wireless and it was just turned off. I’m not saying I think that’s what’s going on. I just think the potential of such attacks hasn’t been investigated thoroughly enough by public institutions.

@ Buck

“Industrial scaled distributed rainbow tables..?”

Closest thing I know of is Elcomsoft’s product.

@ Figureitout

re RobertT’s view

“He already said he wanted nothing to do w/ the project and has avoided most discussions”

He contributed a ton to discussions over the years. He just doesn’t like repeating himself. He’s also got a demandind day job doing what we’re talking about. People like him come and go here. I’m grateful for what time they give us.

“that only like ~100 people in the world are capable of verifying a chip in ways we’re expecting”

Most people in his field are over 40 because they can’t find younger people who can do the job. That’s saying something. Most of it isn’t in books and can only be learned with experience. Mistakes cost a few million each at ASIC time. The companies capable of reverse engineering the chips I can count on one hand. So, he’s right about how rare the skills are to verify something down to the gates at an advanced process node. And that limits our opportunities.

” just takes years to accumulate that experience”

Closer to a decade most chip designers say. I’ve seen many make that claim. The only chips I see the younger crowds doing are pretty simple chips that aren’t integrated into a SOC. (read: useless in practice without other components) Those doing more complex work are typically supported by at least one experienced designer. The typical target is also FPGA because they’re way easier to build on than real silicon. So, even for just making chips work the odds are against newcomers for accomplishing a whole lot. And you guys wanted both function and strong verification of no subversion on top of it. His skepticism is warranted.

@ Clive Robinson

re names

“It appears my name is far from unique and atleast five people involved with ICT at various levels share it in the UK alone, and I’ve personaly met some of them at shows and confrences.”

So I’ve noticed in the past…

” The main reason I spotted it the first time was they replayed a paragraph from Nick P, that was fairly unique in style. It surprised Nick who awarded it a “nice catch” :-)”

Yeah I said “wth?”

On a related note: I also was about to join Wilder’s Security Forums in some discussions until I noticed a guy “from Schneier’s blog” that wrote like me. He used about the same style. The key difference was he was a total asshole rather than an occasional dick. 😉 The whole forum was pouncing on the dude for his behavior. He also regularly used Bruce’s style of doing hyperlinks in his paragraphs. I do it occasionally, as it’s a useful technique, but not as often as him. The guy was cocky, not contributing much, referencing Schneier’s blog/work, and having a writing style too similar to mine. Hence, I never joined the forum as I figured that guy instilled plenty of hate in anyone that would reference this blog or write similar to him. I’d have to convince them he wasn’t me. And worst: I know all the regulars here over the years and have no idea who the hell that was! For all their cockiness, they sure weren’t contributing
here so much. For such reasons, I occasionally feel the need for a strong identity scheme on the web.

@ koita

You skipped past the requirements and immediately went into how to meet them. We need to know the exact use case you want, plus the concerns in it you’re addressing. Then we can comment on various design elements for the camera.

@ mike the goat

I’ve outlined something like this before. If you trust the people, then it’s much easier. 😉 Trying to remember the steps. First, someone helps design a board around the components. Second, the board design is sent to a company that can produce a bunch for us. The components are all ordered and arrive in the warehouse. There’s a sampling room that receives randomly selected chips to perform tests on external behavior. The chips are put on the board by humans or robots [designed by college robotics students]. The boards are connected in a structure that can hold a bunch of them while performing automated acceptance tests on them. Initial, signed firmware is also loaded on them in that process. The boards are packaged in a standard way. Tamper evident seals are used on the packages. Mass orders are packaged differently to save materials.

Yes, such an operation costs something. The cost would be space, equipment, and labor. These can be pretty cheap especially if you do it in a semi-rural area near Interstates and a major shipping hub. Space and equipment might be kept low by doing a deal with a warehouse to lease off a section, plus load/unload the occasional truck. A nonprofit company would handle all of this to charge it at cost and avoid taxes. Accounting, corporate governance, etc is done by the organization designing the main chips. One of my old ideas for initial finance, which is charity if we’re being honest, is to get a person or institution representing a potential buyer of the boards to do it. The potential customer will get their boards first, at cost, and with first rate service. The funder will know they’re getting top quality/security goods, getting a great deal, and doing some charity all at once. My attempt at a win-win deal for this sort of thing.

Nick P • June 17, 2014 1:17 PM

I previously posted a link to my essay in Jack Ganssle’s Embedded Muse on WCET analysis and advantages of I/O coprocessors. I just finished some investigation of the issue that might solve it (or nearly so). Here’s the report I emailed Jack:

Scratchpad Memory: A simple solution to the verification and timing analysis problems?

Ok, Round 2 of this WCET stuff. One problem I have with caching is it’s effect on system correctness and timing arguments. These affect your field just as much as mine. My ideal on-chip memory has fine-grained control, predictability, plenty of space, and uses minimal chip resources. Looking into this stuff more I rediscovered an old technique that embedded guys probably know well: scratchpad memory. I used to love this stuff but forgot it after I had to exclusively work with cached architectures. It met every single requirement on my list minus maybe space compared to some COTS offerings with ridiculous cache sizes. So, I decided to look for empirical evidence for or against it in the problem domain.

Quick tangent: {First thing I ran into was Playstation 2 SoC in my old archives. Developers found its scratchpad handy for minimizing unpredictable delays and accelerating I/O. This made me consider scratchpad’s in my I/O coprocessors for that reason as the I/O programs are tiny and use predictable amounts of internal memory. So that’s another thought for you on I/O coprocessors as quite a few cheap chips have scratchpad. }

I looked into academic work to see if I could find any comparisons of scratchpad and cache, esp involving WCET analysis. What I found confirmed my suspicions: scratchpad memory is what you people need. And before anyone gripes about manual memory management, I’ll quickly add that the tools (i.e. compiler) can handle that for you. The two papers supporting this assertion, one on scratchpad advantages & one on timing comparison, are attached.

So, that problem is knocked out. Automated analysis tools and SoC’s must be developed to put it to use, of course. Next insurmountable embedded issue, please? 😉

Links for the attached files in case you forward them:

Scratchpad Memory- A Design Alternative for Cache
On-chip memory in Embedded Systems 2002 Banakar et al
http://robertdick.org/aeos/reading/banakar-scratchpad.pdf

Scratchpad memories vs locked caches in hard real-time systems – a quantative comparison 2007 Puaut and Pais
http://www.irisa.fr/alf/downloads/puaut/papers/date07.pdf

Nick P • June 17, 2014 7:40 PM

@ Clive

So what do you think about scratchpad’s over caches for better efficiency and easier timing analysis?

Nick P • June 18, 2014 2:55 PM

@ Incredulous

The rule is limiting like some of the others. Even I butted heads with the Moderator plenty in the past and promote strong individualism. Yet I mellowed out as the rules overall effect has been to promote useful discussions without the flamewars, trolling, and other Slashdot-like issues that reduce quality.

This has been the case for the 7 years I’ve been here. It’s helpful for readers as they don’t wade through pages of nonsense from seemingly hundreds of different people to find the one thoughtful comment or the one they were going to reply to. It’s helpful to writers by pushing their efforts in a beneficial direction. Things have heated up a bit Post-Snowden, but the rules are partly there to keep passion from drowning out reason.

So the rules will probably stay. As the expression goes: “If it ain’t broke, don’t fix it.” And this blog more than works: it’s produced more solutions to major issues than many others combined.

Nick P • June 18, 2014 6:24 PM

@ Wael

“Someday we’ll have a nice chat about LLVM. At the moment, it’s performance is suboptimal, and I am ready to ditch FreeBSD for that reason… Too bad, was a good OS.”

It might have to do with the fact that GCC has been built on since 1987, often with sponsorship, while LLVM came into existence in 2000 with sponsored development starting in 2003. It’s not quite a baby in the IT world, but it’s far from grown up. Give them time.

OpenBSD team’s reaction to GPL 3’d GCC was more unusual: they’re continuing to maintain an out of date GCC version with security fixes. LLVM or not, having something easier to maintain than GCC with a permissible license makes a lot of sense for BSD teams.

Nick P • June 19, 2014 12:34 PM

@ Mike, Wael

Now that’s interesting that Mike used FreeBSD post-GCC without noticing the difference. Wael was griping about the performance of FreeBSD under LLVM. Contradictory experiences. One thing I recall hearing about original switch to LLVM was they did it in an update to a new version. Those updates have been changing a lot more than the compiler. I’m not entirely certain anything about performance, good or bad, can be attributed directly to LLVM unless we could test it on two feature-identical FreeBSD codebases. Or codebases of something simpler with many features and ease of real-world measurement.

Note: I simply don’t do microbenchmarks as everything there is “nearly as good as C.” Yeah, that’s why those scripting and functional languages took over the embedded, OS-developement and HPC worlds. (rolls eyes)

@ Wael

I saw your security concerns. I’m sure things will be found. Things are still being found about how GCC handles things. Even GCC’s exception system was turned into an interpreter for malicious code I believe. The switch away from GCC should have benefits in the long run as GCC is so complex I couldn’t do a thorough security analysis and many couldn’t even extend it without great work. LLVM is both better structured and designed for “lifetime program analysis.” Small projects have built onto it power analysis, thread safety checking, and so on.

Such a system should have long-term benefits for security. Although, current situation is indeed unknown without more review.