Schneier on Security

Nick P • February 23, 2016 11:46 AM

@ Nix

Why use tactics (canaries) when you can use elite strategy (memory safety)? Try compiling it or utility apps with Softbound + CETS to see what happens. Cutting-edge tools need more testing so their problems can be fixed. Only issue I see is that Softbound is LLVM, not GCC. Someone once told me you could get portable code out of GCC compiler arguments but idk. Might be a solution there if any LLVM vs GCC issues turn up.

Note: If performance hit is too much, try the lesser invariant of Code Pointer Integrity that still provides quite a bit of protection usually at single-digit percentages of performance loss.

Nick P • February 25, 2016 11:38 AM

@ keiner

“20 years software review by the NSA, that’s hard!”

I don’t see NSA in the linked document at all. Besides, they wouldn’t get a real pentest unless they were certified at EAL5 or higher. Basically nobody does that. So, NSA does limited black-box testing and feature checks based on paperwork (eg user guides) submitted to them. Common Criteria EAL4 and below are a sham.

“The downside: PC-BSD, the only usable desktop version of BSD”

I just reinstalled my system. Went with a Linux distro because I expected exactly that.

@ Marc Espie

re OpenBSD

“OpenBSD of course. The old existing code can be a bit crufty (filesystem layer in the kernel), but we’ve been cleaning the code for decades, and we do try much harder than the others to not let anything pass (systematic eradication of anything that’s broken).”

I’ve always given you all credit for that. The proactive approach shows much lower defects and better documentation. It’s still a UNIX with a huge TCB, plenty of covert channels, and underutilizing mitigation technology coming out of CompSci. My old scheme for producing vulnerabilities for it was just to watch the mailing list then weaponize what was posted before a patch went in. That people used it fire-and-forget sometimes neglecting updates meant the attacks should work. I’ve always been surprised to not see anyone doing that. I wrote it off due to a combo of almost non-existent market share and high effort required to beat its mitigations.

Nonetheless, it’s the highest quality of the UNIXen. I’ve always advocated someone put it on top of a secure microkernel in Nizza architecture style to get the best of both worlds. One could escape both monoliths and C by running security-critical components directly on the microkernel in a language (or C subset) amendable to highest analysis or full mitigation. Good middleware can handle the interface security automatically or semi-automatically.

re languages

“Thinking that if you change language you will get better security is a common fallacy. Get off your soapbox. ”

That’s not true at all. Both CompSci and industry studies going back to the 60’s proved you wrong conclusively: choice of language had huge impact on number of defects, ease of integrations, and ease of maintenance. Some studies, esp by defense contractors, looked at various languages in use including Fortran, C, C++, and Ada to determine if it was worth a switch. Ada had less defects… usually half… than any other except one outlier where C++ and Ada had the same while doing better than C.

Other examples. Burroughs in 1961 coded the Tron villain, err their MCP OS, in a version of ALGOL which didn’t have C’s undefined and unsafe behavior in default use. It kept pointers safe, bounds-checked arrays, protected the stack, and so on. MULTICS used PL/0 because of safer string handling (you’d know about that) and made it use a stack where incoming data flowed away from stack pointer. Wirth’s languages, used in OS’s, had all kinds of checks on data types and interfaces while compiling & executing very fast. Hansen’s Concurrent Pascal in Solo OS was immune to dataraces and usually deadlocks. Eiffel’s SCOOP was immune to data races w/ some projects showing deadlock & livelock freedom. Army Secure OS combined tagged CPU, security kernel, and high-assurance runtime for Ada to let one write rest of apps in Ada without worrying about what’s underneath. SPIN used Modula-3 for OS-wide safety also with type-safe linking. Most recently, an OS was developed in Haskell: a language whose type system & easy, formal verification can provably eliminate more problems than I can list here.

So, history is definitely not on your side there. There was one system after another that was straight up immune to the problems that plague UNIX’s and C-based projects. They did that with a combination of better hardware, software design, and/or language choice. The language choice eliminated much low-hanging fruit. Plus, certain choices made further analysis easier rather rather than so hard that people got their Ph.D’s trying to detect basic problems. 😉

Now, that doesn’t give reliability or security by itself. Plenty more areas to worry about and mitigations to perform. Just establishes a foundation that makes a secure system easier to build and maintain. Not to mention, one’s tools make the common things (eg pointers, arrays) should be easy to work with rather than hard.

Note re Gerard’s claim: I challenge you to skim the chapter titles and methods of that Ada book I linked. Your words indicate you’ve never really looked at Ada to see just how many issues it eliminates or catches. Remember that it was designed by experts in response to industry’s, real-world problems to systematically eliminate as many as possible before the program ran. Whether best design or not, it’s safer than C in so many ways one has to write a whole book to describe them. And that’s not even the height of what language design can prevent which is happening in functional programming, including functional systems languages.

@ Anon

“I’d prefer to see an attempt made to re-write core software from scratch, knowing what we do today. If it breaks compatibility with some things, tough.”

I semi-agree. I listed many architectures better than UNIX here. Knowing C’s history, there’s also good reason to ditch it for one of the old (Modula-2/3, Ada, PreScheme) or new (Rust, SPARK, ATS) languages for systems programming. Hell, there’s been typed assembler languages that are both faster and potentially safer. Crazy, eh?

That said, what we have in our UNIX OS’s and libraries are decades of accumulated wisdom. They ran into all kinds of problems in hardware, software, networking, etc. The solutions to those problems might get little to no documentation. Yet, their fixes are in the code. Clean-slating the code, like MirageOS for instance, gives the benefit of new tooling but drops much of that prior wisdom. Teams could spend a long time re-inventing that stuff. Hence, the other strategy of trying to evolve and polish the existing stuff.

Strategies for doing that include safe C’s, virtualizing them, obfuscating them, hardware reliability/security tricks, and so on. They work to a variety of degrees. They just haven’t been applied to a whole kernel and toolchain yet. Might get us further than doing everything from scratch. That’s why projects like Cyclone, SVA-OS, Nizza, Softbound + CETS, etc are invaluable in letting us gradually improve what we have in case other stuff doesn’t get written.

@ Clive Robinson

“What you don’t see mentioned very often is attacks going up the computing stack. The most known about such attacks are via the DMA controler used in high speed IO (FireWire etc).”

That’s on purpose. There’s a whole literature of techniques dealing with that side of things. Essentially, the strategy is to force all that into either a known safe or known failed state by the time it hits memory. Also, restrict what memory it reads or writes while applying tags if applicable. Then, the valid data or failures are dealt with at a higher level of abstraction that’s safe in how it operates.

“Thus an attack from below will alow “input checking” to be bypassed etc and most of those “safe language” features as well.”

What you’re describing is not a failure of safe languages but a failure or consequence of existing approaches to develop hardware. There are examples of hardware that do not have these problems because they were specifically designed to avoid problems. Further, a RAM expert told me problems like Rowhammer weren’t unavoidable so much as industry cutting corners on QA for a long time. So, the solution here is to use the same mindset when developing hardware: languages that make safe expression & analysis easier; correct by construction transformation/optimization tools; formal & test-based equivalence checking; gate-level testing; physical testing of various modules to ensure DSM or manufacturing problems don’t change logic; rad- or fault-tolerant logic for key modules with TMR internally (aka AAMP7G) or externally (aka NonStop).

Systems have been built with first pass, inherent safety/security, and at comfortable abstraction for developers. Two I like to cite are Sandia’s SSP/Score processor for embedded Java and Rockwell-Collins’ AAMP7G for stack machines. They were exhaustively analyzed to find logic, environmental, etc faults plus at least one done on rad-hard process. Result is no failures in field on the record so far while all coding can be done at a higher, safer level. So, the model is to combine secure methods for developing hardware with safe/secure languages or abstractions for software to get an integrated hardware/software system that’s immune to most problems of both.

And then install backup, recovery, and monitoring mechanisms to handle the inevitable failures called known unknowns and unknown unknowns. And then add those into the requirements of the next release. 😉

@ Nix

” even if it did significant parts of it are assembler and it does all sorts of deeply evil things, particularly in early startup (and we have to be aware of that even when ld.so is not being considered, because the static library does many of the things ld.so does at startup using un-rebuilt objects from the core libc — things like memcpy() which you really do want to keep an eye on in the general case).”

I’ve read about that mindset and resulting problems before. The solution is to begin fixing that so it’s at least possible to analyze or transform it. Just piece-by-piece improve it so the cruft and horrors will eventually be gone. The result is something all these wonders from CompSci and industry can work with. Then there’s efforts like musl replacing it entirely. Interesting results there. Might be able to work on those if not glibc. 🙂

Note: Your name also reminds me of a distro that’s finally fixing huge, unnecessary issues in both package management and filesystem organization. Amazing things happen when people see one of the root problems then solve it.