Schneier on Security

Nick P • June 27, 2014 7:39 PM

UNIX philosophy proves it’s inherent insecurity once again as old tricks are rediscovered.

http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt

Nick P • June 29, 2014 2:07 PM

@ Benni

“The million dollar question is now how the nsa does this?”

There’s so much attack surface in a smartphone I’m surprised they don’t assume all kinds of people are hacking them. Main chips, microcode, firmware of chip, firmware of devices, privileged software, critical libraries… the list goes on and on. The encrypted phones typically minimize that a bit instead of eliminate it. And they can be subverted via human or extra-legal methods if a black box attack isn’t available. Blackberry also uses centralized security architecture, is hosted in the U.S., and has plenty of features (read attack surface). So many possibilities there. It’s always been hard for me to understand why foreign companies or governments trusted them for private communications.

The solution the German government went with is here. I’m not sure what it offers as I can’t read the German. That it leverages Blackberry is already a risk factor for me. If I were German govt, I’d have handled it the way the French did: a simple, secure phone designed by a local defense contractor with limited distribution. Germany already has one long-time leader in encrypted phones (Cryptophone) and a skilled security engineering company with phone experience (Sirrix). The former was smart enough to harden the phone OS and release crypto code for peer review. The latter employs Christian Stuble whose done excellent work in reducing TCB of systems with microkernels.

The short cut to private communications is for German government to give a large amount of money to these two companies to build a secure phone. If not, I’d have gone with this Cryptophone as the default option. It’s the most similar to a Blackberry, but with low attack surface at OS level due to years of hardening. If they were about to make a huge purchase, they’d also have leverage to negotiate some custom improvements they wanted as part of the deal.

Instead, the German government seems to be buying an enhanced version of an insecure, possibly subverted platform. That doesn’t seem smart to me.

Nick P • June 29, 2014 11:25 PM

@ mike the goat

re Marketing Secure Computers

There have been attempts to market such a machine. The first were companies trying to leverage the assurance of “Trusted” operating systems. Here’s an example that’s marketed to protect web applications back in the mid-1990’s from a number of problems. In this case, the business case is loss avoidance by choosing a product that avoids most common risks.

The next business argument I saw was for intellectual property. This is a general security argument that applies to more than OS’s. Rome argues CMW’s could allow mutually untrusting parties, like at a tech incubator, use the same machine without compromising trade secrets. Arguments are made for databases, medical records, and security-critical services (eg Kerberos) that need extra protection.

Better security is an argument on occasion. 😉 Let’s take KeyKOS, for example. It was highly secure (B3-equiv), enforced POLA throughout, ran on existing hardware, isolated critical apps, virtualized legacy apps, and provided built-in persistence of system state (unique). It was much easier to argue that such a design would be safer or more reliable, along with being usable for the business. Interesting enough, the clean interfaces, separation of concerns, and minimal shared state that gave rise to KeyKOS’s advantages led to yet another that’s a selling point itself.

Extensibility and maintainability you might not have seen coming. A system that’s modular, using information hiding, avoids pointer magic, limits damage, uses clean interfaces, and so on is much easier to maintain and extend. A few distributed OS’s, such as CTOS, bragged on how easy it was to add new features. SPIN is probably the champion here as they got most of the benefits by writing it in Modula-3, then added type-safe loading of code into running kernel for performance. I know AIX and Erlang feature that kind of thing as a selling point so it should benefit a secure system’s business case.

Reduction of admin work and downtime. IBM tried to make a business argument for SELinux focusing on reduced administration and downtime associated with vulnerabilities. I don’t have the link on me. Their argument was that the mandatory access controls contained many types of vulnerabilities. Dealing with each vulnerability would’ve taken administration time and risk. The exploitation of these vulnerabilities, if resulting in loss of control, would also contribute to downtime. So, they basically just ran the numbers showing what the situation cost with and without MAC. And then use that as an argument for SELinux.

Note: They make similar arguments for mainframes and IBM i with quite a bit of success.

Reduction of amount of equipment. Green Hill’s loves this argument with their INTEGRITY-based virtualization solutions. They use one of their RTOS products, esp EAL6+ INTEGRITY-178B, as a low-TCB base layer. They then add virtualization, isolated networking, trusted path, etc. Their argument is that you can replace many separate pieces of physical equipment with one device that securely virtualizes one. Each PC has a physical, software, and administrative cost. The solution is worth the money if it costs less than what it replaces while doing what it says it does.

Variation of above: BYOD. The idea here is people bring, manage, and support their own devices. A piece of mobile security software, often virtualization, is used to create two instances on the phone: work and personal. The software provides a brick wall between the two, along with features like remote wipe for business side. I’m not saying that I buy the BYOD promise. I’m just saying that it’s infeasible without secure devices. Therefore, BYOD-enabling security software can argue that they save the company whatever their mobile costs are. There’s a significant number of companies working this angle.

Compliance. There’s compliance issues in healthcare, payment industry, federal, financial, and so on. They typically include INFOSEC requirements, especially anything that helps an audit. I know that many companies market their security software or systems for this. I’ll add that making things easier to audit, like some hardened OS’s do, could be an advantage in one of these arguments. The extra integrity protection is definitely an argument.

Anything legal and recorded. Certain secure solutions have very strong integrity arguments (eg X9.95 timestamping). The use of one of these to support a claim before a suspicious party, such as a court, might bolster the argument. You just need to hire an expert that reviews the solution and tells the judge he’d never doubt what it said. Then, your evidence looks a bit better than it did and maybe even better than other side. I can see benefits in contract negotiations, voting, and so on.

Reducing inconvenience. I save this one for last as I have mixed feelings on it. The idea here is that typical systems create many burdens for users trying to avoid problems and the eventual compromises are time-consuming. The system, if quite seemless, would avoid most such issues. The main actions would be protected by default with little to no effort on user’s part. The basic protections it has prevent, contain, or enable speedy recovery from most attacks. If not too expensive, this kind of benefit might be justified. I believe it’s been a selling point for Macs, browser sandboxes, and quite a few other successful products.

So, there’s some off the top of my head. They can be used individually or in combination. Should help sell a solution. Truth is, though, that secure systems of any kind are a niche market of niche markets. Good luck is all I’ll say. NSA and such give a nice business boost but it’s still barely a market. Wait, that leads to the final selling point.

Those pesky, SIGINT-loving, intelligence services. “Are you worried about NSA listening to all your diplomatic phone calls? Is your software backdoored? Is your network their property? Do you have an aversion for Hellfire missiles? Are you concerned that every competitor’s product is certified by NSA (EAL2-4) to be easily hacked? Well, you’re in luck because we have a product certified to their highest levels that can protect you from them! And for only 5 easy payments of $9,999…”

Nick P • June 30, 2014 7:41 AM

@ Clive

re concurrency

Evaluating his four items. Non-blocking I/O is definitely a requirement as it’s proven it’s value from 60’s mainframes onward. User-space concurrency can help, yet systems in the past showed putting it into kernel or hardware works too. Easy messaging has proven to be important. Advanced scheduling is vague so I can’t comment on it. All I’ll say about scheduling is being able to meter workloads and prevent them from halting total cluster operations is quite important.

So, nice points but I’m not sure about his conclusion. Tanenbaum might’ve said you just need the right OS and techniques. Most of the older distributed or clustered OS’s were built using old languages without a runtime. And nobody ever accused SGI or Cray of failing to scale. 😉

re Blackphone

Seems they did a good job far as a private Android distribution. I expected they would. The review in the article actually says nothing about how secure the phone is. The attack vectors have to be enumerated, the countermeasures (if present) enumerated, and reviewers must go through the lists to see what might work. One also must analyze anything unique to Blackphone, from changes to OS to their software, to find potential issues there. And even if that’s all good, there’s still the whole subversion risk: U.S. company, located in D.C., and affiliated with another that brags about their Navy SEAL’s on staff. Couldn’t imagine any NSA influence happening there… 😉

Nick P • June 30, 2014 8:36 PM

History and categorization of I/O handling methods

http://people.cs.clemson.edu/~mark/io_hist.html

The link was a good read as clean-slate efforts might benefit from rethinking I/O. It’s no secret I prefer coprocessors such as Channel I/O. Most are going with interrupts. Some homebrew chips will typically be PIO. In any case, I figured people might find useful a categorized list of how previous systems handled I/O.

Once again, Burroughs B7700 was ahead of me:

“Reserved locations exist in main memory that define head and tail pointers to I/O device request queues and I/O completion block queues. Queue manipulations by the CPU and I/O modules were atomic actions. Any IOM could handle any device, but a start I/O instruction issued by the CPU begins IOM processing on a specified device queue. IOM processing continues until an error, interrupt, or empty queue. The CPU polls the completion block queue, or, optionally, interrupts could be generated on completion of each request.”

That matches one of my recent designs almost exactly. The design called for two processors, one compute and one I/O, to run in parallel with memory being the main way things were synced. This allowed me to keep compute processor (running trusted code) totally in control of execution, ignore the effects of interrupts on most actions, and determine how asynchronous the execution was for timing channel issues. The key difference is my design calls for strong memory isolation between the two’s working memory, with specific shared regions for I/O.

Nick P • July 1, 2014 1:08 PM

@ Iain

Thanks for the explanation.

@ Benni

That viewpoint makes plenty of sense. 🙂

@ CallMeLateforSupper

This thing. Your company used the real deal, then. I think the failure was mainly due to IBM mixing two markets that just didn’t mix well. Of that line, the PC/370 was most interesting as it was just a card. Reading on I see the S/390 Integrated Server used a Pentium 2 for I/O Service Processor. That a P2 met the performance requirements for even a lower end mainframe is hopeful for new developments using open cores that are typically 100-400Mhz.

re Channels

Yes, the Burroughs model should sound familier to an IBM admin. Most of the major mainframe vendors used I/O coprocessors and channels, although the specifics are different. I’ll be honest that I still don’t understand how Channel I/O works on IBM just because the descriptions confuse me. There’s Channel Subsystems, Channels, Subchannels, Service Processors, Control Units, actual wires, and so on. Here’s my abstract design for my own Channel I/O so far:

1. Compute Processor, main memory, etc. obviously
2. I/O processor with RISC/CISC core, acceleration of I/O critical functions (eg endian conversion or checksums), DMA engine, onboard SRAM, and physical connection to various devices.
3. Device interrupts go to I/O processor.
4. Device drivers and maybe I/O related OS functions run on I/O processor.
5. I/O processor directs DMA operations.
6. I/O processor might update parts of memory that are I/O related (esp status)
7. I/O processor has some way of communicating with compute processor.

That simple. Most of what I described could probably be integrated on one affordable FPGA, not to mention a SOC. IBM’s model is just too complicated for me although it might be a necessity I don’t understand yet due to Channel I/O being new for me. I read Burrough’s model, though, and didn’t feel so overwhelmed. It even sounded a bit like my design. 🙂

I’m still open to new design points on the I/O system as it’s still on paper and exploratory. The key points are: computation on one processor, I/O management on another, isolation of memory spaces for these, and ability to leverage existing chip-up security approaches to protect code on both. The last thing is easy to do if the design is simple. And what we use to protect I/O processor might be different from main processor or it might reduce cost by reusing main processor. Many tradeoffs. Yet, I’m sure there’s a construction that has most advantages of IBM model with cost and simplicity of PC model. Maybe simpler due to fewer interrupt-related issues.

“it was readily apparent that becoming “I/O bound” was simple to arrange!”

Yes, I still run into that problem on some network devices and USB mass storage. A USB backup kills performance on some Linux desktops. If it had I/O coprocessor, I’d probably not even notice it so long as I wasn’t doing anything I/O dependent. And I could always prevent that issue by copying my work to a RAMdisk tied to compute processor before starting the backup.

Nick P • July 2, 2014 11:28 AM

@ Gerard, Petrobas

ParaSail is a prototype so obviously out of the question. Ada and Active Oberon meet Gerard’s requirements, though. Both were used to write OS’s. D is decent for people of C++ background. Go is aiming at that. There’s also Java subsets and runtimes for systems use (mainly embedded). BASIC dialects such as PureBASIC are still popular for being more readable and safe, while still fast. (No good, built-in concurrency though). I just found SuperPascal. It’s interesting from a concurrency perspective, but I’d not call it production.

I’ll note that my research on safe/secure OS’s show that some of Gerard’s requirements might be handled by a core kernel or runtime. It wouldn’t be needed in the language itself. The GEC computers, for example, had a “Nucleus” with concurrency, exception handling, memory management, I/O, and more built-in. The code on top, including OS, just made calls to that. Then the language you use doesn’t need that stuff built-in.

@ CallMeLateforSupper

I’ll try that. I might also be able to find a local mainframe programmer that could explain it to me. We have a lot of big banks, warehouse firms, etc out here that almost certainly run mainframes at HQ. The admin might enjoy the rare moment that someone is actually interested in how their dinosaur works rather than laugh at them. 😉

“[2] a control unit is not part of a channel, it is part of an I/O box (tape, printer, disk, etc.). It is the interface between a channel and that I/O box.”

I couldn’t get my head around the need for a control unit given the I/O functionality on the main chip and the device. And now you say the CU is what the device has. That makes… SO much more sense. 🙂

Nick P • July 3, 2014 6:26 PM

@ Iain

Thanks for the info on monitors. It might come in handy. The IDE thing might be fun for the hobbyists here messing with 8- and 16-bit systems. I won’t use anything less than a 32-bit as there’s already open cores for them. Heck, the SPARC T1 and T2 are open too. And the third core on this page is quite useful if one’s building in IDE/ATA support.

Nick p • July 4, 2014 11:49 AM

@ k9

Sounds like the start of a budget movie. My experience in this area was a long time ago when one of my adversaries tried planting evidence on my computer to get me in heaps of trouble. I get officially investigated and interrogated before I know anything about it. The key part of the evidence was the time on the files. They believed their network and systems were locked down so the timestamps were valid. So, I had to show that both weren’t true.

For the time part, I made a program that changed system time and another that changed metadata on files. I made both in Visual Basic 6 using simple search results to show them that the least competent technical user could pull it off. I also breached their network in under a minute due to its configuration, popping up messages and altering files on various computers. The combination showed the opportunity, but they still needed a name and motive. So, I’d have to try to explain why that was infeasible and even irrelevant when discussing hackers.

In the end, they still didn’t buy it. My remaining time with that organization was short and I lost that reference. Taught me important lessons about perception vs reality in IT security, along with motivating me to deal with some issues. Anyway, modifying system time could destroy careers back in the day. I imagine similar stuff could happen today.