Schneier on Security

Nick P • April 23, 2014 2:03 PM

I’m busy most of the day so I’ll write my real post later on. For now, I’ll mention that there are a number of languages that prevent many problems in web apps by design via type system and/or compiler. Example below:

http://www.impredicative.com/ur/

@ RSaunders

Looked at your comment and found a present for you:

http://flibs.sourceforge.net/fortran-fastcgi-nginx.html

Nick P • April 23, 2014 8:48 PM

On Secure Web Application Development Langauges

There are several approaches to this. The most common approach is to create frameworks that handle security aspects. Another is to use tools to analyze the web application to catch defects. Another is to use a middleware that mediates activity and applies security policy. Another is to extend an existing language to prevent security problems. Yet another is to create an entirely new language specifically for solving the problem. I’ll include examples of everything but the flaw finding checkers as there’s lists of them elsewhere.

The simplest is including security in a framework. There’s quite a few that do. The best effort for legacy apps is OWASP Enterprise Security API. Combining that with a safe language would go a long way. There are a number of web frameworks for safe languages that leverage their type system for safety and/or security. Lesser known languages with such frameworks include Ocaml, Haskell, Ada, Eiffel, and Scala. (Links are frameworks.) The resulting security level varies with each of these, of course. And any integration of external (unsafe) code is risky.

The gateway approach goes a long way back. It was the original security solution to all sorts of problems in the Orange Book days. There were mail guards, trusted network processors, database front ends, and so on. I even applied a version of this in older designs to secure client-server apps. The one example I know of for web apps is SPECTRE. It works on legacy code written in multiple languages, but the gateway was built with Ocaml if I recall correctly.

The extension approach is halfway between a framework and a dedicated language. The idea is to modify the language-level to help it do its job better while leveraging existing code or experience. Examples for endpoint protection are Joe-E (server) and Caja (client). Of course, it’s the interactions that cause many web issues. The best project I’ve seen that extends languages & tools for this is SWIFT. It does both information flow control & automatically partitions code between client & server.

The new language approach is another route. This is usually chosen to get rid of the multiple languages problem, but sometimes for security benefit. SELINKS modifies the LINKS web language to boost security. Opa integrates all the development while leveraging powerful type system to catch errors. Ur/Web prevents an amazing amount of stuff using an advanced type system. There’s another being developed at INRIA based on F# that will probably be interesting given what ML-style languages have accomplished in this field.

The right choice depends on one’s requirements, of course. However, if we just look at technical data, the best choice is a combination of above tech and ideas. For legacy systems whose code can’t change, is to use something like SPECTRE along with security tech for that langauge/platform. If you can change the code, use one of the solid frameworks while refactoring out risky stuff. If it’s a new project, use one of the safer languages or SWIFT. Also, if there’s any native code, isolate it with a tech such as Native Client, write it in a language like Ada with checks on, or both.

I think it’s very possible to write secure web applications with little effort. These will be secure against known classes of attack, of course. New discoveries might invalidate the security. Nonetheless, starting with safe languages & constructs for securely handling risky issues is a superior option in the long run regardless of what schemes are discovered. The reason is that the choice provides a strong foundation to build new technology on with lower odds of shooting one’s self in the foot.

So, now that you know this, go write some secure web apps to replace the popular ones! 🙂

Nick P • April 24, 2014 9:24 AM

@ Anura

“That said, .NET websites do have a tendency to be misconfigured to show the exception with the stack trace… combined with a debug build being deployed and I’ve seen cases where invalid input prints out the code that builds the SQL; very useful to an attacker.”

I’ve seen that! It was on a major web site whose name I can’t recall at the moment. I used a form of some type, then saw what looked like a debug dump. I was thinking “should the user be seeing all this crap? Or should it have been emailed to admin or developers?” Two options, one good & one bad for security, which will .NET choose? Result: “Doh!” (Homer Simpson)

@ Autolykos

” That argument, however, only translates to C++ if the guy writing the code still uses C++ as he would use C.”

It’s an interesting claim. Most empirical studies I’ve seen of C++ support my comparison to C in vulnerability. However, the way C++ was being used was like an enhanced C. I’d actually like to see a vulnerability analysis of your safer style of C++ to see what it’s actual risk is.

@ Mr Pragma

“C (and consequently C++ by intention or not) was created as a system language; in fact, it was created for the purpose to create an OS (Unix) for a new architecture.
While some like to bash C/C++ for its very raison d’etre I do agree with K&R (and Stroustrup). Seen from the perspective of then, at that time, C was an elegant construct and a major progress.”

I actually agree with you about that. I only criticize C/C++ for current use. Back in the day, it made plenty of sense to make something like C at least.

” I take it as a strong hint that during decades that camp came up with only 1 “major” attempt at safety, Cyclone, and that Cyclone is a pretty much ignored and little taken care of creation.”

Don’t forget D. That project puts in solid work to make a better, safer C++. They deserve some credit. Like you said, though, almost no take up.

“The mere fact of java being in Oracles hands (and the way they handled it) tells me loud enough to avoid java fervently.”

Absolutely. What they tried to do with Android speaks of their character plenty: they have none.

“On a sidenote: I sometimes wonder whether that whole language thing also tels a lot about usa and europe. ”

Americans invented the first safe machine (B5000), the first implemented HLL (Short Code), the compiler (Grace Hopper), BNF form (Backus), analysis of fundamental algorithms (Knuth), formal code reviews (Fagan), first implemented theorem prover (Logic Theorist), functional programming (Lambda Calculus), the field of computer security (Anderson Report), formal vulnerability assessment (MULTICS evaluation), covert channel analysis (Kemmerer), and formal security assurance process (Orange Book). Americans also coinvented ALGOL, which set the stage for languages you named. If anything, I’d say certain Americans laid the foundation for safe/secure computing much like certain Europeans (esp British) laid the foundation for computing.

So what of today? I’m the authorative source on all things security research having reviewed literally thousands of papers spanning decades. Early on, most of it was predominantly in America with us being most concerned & with lots of funding to solve the problems. Today, most of the research in security & better programming is spread across US and Europe, with some in Asia & Australia.

I can’t see a definitive pattern. There’s good work going on in both continents across the broad range of topics. My current European favorite is Xavier Leroy’s Gallium team in France because their group combines theory and practice pretty well. They also produced useful stuff for rest of us: Coq, Ocaml, CompCert C compiler, and MiniML compiler on the way. Not sure of an American favorite although there’s quite a few good ones. I’m not so biased in that I think international efforts are best for this field, esp when one considers the risk called subversion.

As for culture, there does seem to be a difference in culture. I wonder if it’s the capitalist/individualist vs socialist mindset. I noticed that tools such as Modula had a decent amount of takeup in Europe, whereas in US it was mostly C/C++. I know over here the profit and time to market pressure make a quality development process a liability. Well, at least appear to be to management. There’s also a ton of legacy code in C/C++ and people who can maintain it. So, these incentives seem to combine to prevent safer languages and platforms from taking off, while reinforcing unsafe practices. I’m not sure what it’s like in various European software shops. I’m guessing you’re European so maybe you could give me a perspective on that in whatever countries you’ve worked.

“My personal preference is Modula/Oberon (although compiler support is thin and for few architectures only) and Ada 2005 (yes, I love 2012).”

Same here. They seem to make all the right design decisions & are quite versatile. Both sets of languages have been used on hardware ranging from desktops to microcontrollers. Ada was also used in a mainframe-type system (BiiN) and several highly secure systems (ASOS, SAT). There’s also empirical evidence backing Ada reducing vulnerabilities & being more productive than C. The support for C is a practical decision that made sense.

“As far as scripting is concerned I like Python (extremely well thought out, very productive, brilliant minds and deep zen behind it and lots of batteries included). ”

We think alike twice. Check out Stackless Python and Cython, btw. The Python camp just keeps on getting better.

“So I thought you might be interested in some of my thoughts.”

Very interesting post. 🙂

@ L

” doesn’t make much sense, since memory management, length and a lot of other stuff are safe in c++. sure, other languages might be better. All i’m saying is that C and C++ are not the same.”

They’re surely not the same as I’d take C++ over C wherever possible. Yet, it’s hard for me to believe C++ is as safe as you say when professional C++ developers and researchers are working their butts off to make it safe. The existence of MISRA C++, Ironclad C++, research into making it safe, and tons of vulnerability analysis tools make it hard for me to mentally connect “safe” and C++. Although, the newest standard might improve that situation. I havent’ reviewed it as we already have safe, fast, readable languages with good IDE’s so why bother.

Funny thing is, I could teach an average C++ programmer how to safely use Modula-like language faster than I could teach them how to write secure C++. I did this more than once. Each time, I pointed it out to them & enjoyed the look on their faces. One also commented that the safer language resembled the pseudocode he wrote and translated into C++. He said using the safer language eliminated most of that mental translation step. All of them also appreciated the near instant compile time as they could develop-compile-run without loosing mental flow. Ah, the joys of a very well-designed language. 🙂

Nick P • April 24, 2014 10:39 PM

@ Mr Pragma

re C

I meant about what you meant, despite using only one sentence. It’s quite useful for what it was designed to do even to this day & has a ton of tool support + expertise. The need for such things is why I like developments such as Cyclone, Typed Assembler, LLVM, etc. Gives us alternatives to C to solve this problem. For instance, ignoring syntax risks, C forces a certain structure on your program that might pose risks upon integration with a safer HLL (e.g. infamous Ada-C linking vulnerability). Coding directly in assembler or something else ultra low level + efficient might avoid this.

I’ve even considered coding in LLVM assembler, compiling that to whatever ASM I’m using, & integrating it inline in a safe language for performance critical part. That’s cross-platform, low level, easily optimized code without C’s structural decisions. C & an FFI is certainly an easier option, yet I figured I could throw a tool together that automates hard parts of the LLVM option. Also, high level assemblers such as Hyde’s HLA & Linoleum have promise if further developed.

While your at it, check out PL/S. It’s a PL/I variant without a runtime that IBM uses for mainframe OS development. They’ve improved on it for years and consider it a trade secret of sorts. Here’s one paper describing it. The cool thing about it is it’s still quite high level, yet it lets programmer specify per function how compiler handles certain things. So, it can be extremely efficient, safe, or some combo between. Also supports two different kinds of inline assembler according to one source.

“But frankly, I feel that D doesn’t get widely accepted and used for a reason. Looking closer I found the very core, the “C mindset” again in D.”

That’s the point. The safer languages didn’t replace C/C++. The one’s that did have takeup are too inefficient. So, it’s kind of a compromise where C/C++ people create a language they hope C/C++ people will like that’s quite efficient. This is case for D, Cyclone, and Ironclad C++. I’m not advocating these over better options. But, I do give them credit for taking initiative to win C/C++ crowds over & getting rid of some big problems in C/C++.

“Frankly, I’m afraid, no matter how much one works around that approach one might create an indeed better C++ but one will not achieve to create anything really comparable to the Pascal … Ada … Eiffel line.”

I agree with that. Plus, I hate people reinventing the wheel. If they want to exceed those safe languages, go right ahead. DECA and Habit come to mind. If they want to bring their C++ garbage in feature parity, it’s a waste of effort. They’re better off being clever bringing the safe languages into performance, tool, and library parity. That would be quite beneficial. I also like your “pimped up assert” comparison. Haha.

re Americans invented first

The point was less on absolute first and more to just show Americans have been pulling their weight on the issue for a while with many great contributions. That’s all I was saying. Over here (and in general), quality and security are still minority players in software market. So, much of America’s best work goes unused and, worse, unremembered by industry as a whole.

One example. I love listening to aspiring secure coders talk about canaries and other clever methods of dealing with stack overflow issues. Then, I point out MULTICS beat all the stuff by simply making stack flow away from control flow pointer. The “Holy S***” moment on their faces is priceless. Yet, it’s also sad as not one has ever heard that stacks can be made immune to overflow or even figured out the obvious themselves. “Why do we make attacker data flow toward the critical location?” The question never asked. Many, many, many things like this over here. World-wide, too, far as I know.

“Yes, I agree, from what I see, in the usa the marketing push is stronger than across the ocean. French or German developers can be pushed only so far to produce sth. lousy but shiny and (why are they almost always overlooked?)”

Interesting. At least I give them credit as often promote both TU Dresden (TUDOS projects) and INRIA’s work. Great work at both.

“the Russian are very favorably influenced by a very strong academic system and tradition. Actually, I think Russia is among the stronger supporters and users of Modula and Oberon (and probably would use more Ada if it hadn’t the ugly american dod smell…). I’d bet anytime that the quality of Russian code is considerably better than american code (on average).”

I didn’t know they used Modula and Oberon much over there. Matter of fact, now that you said it, I recall some Russian forums on the use of Blackbox Component Builder for Component Pascal (Oberon successor). So, they’re using it and on the cutting edge of it.

It’s known that Russian programmers are skilled. The clever malware writers are often Russian & continually invent clever tricks. The reason, though, might not just be education or culture. One Russian programmer said people often get only limited access to computers. (Cafes? Colleges?) There’s only so much time to type in the code, test it, and so on. So, he said Russians put much more effort into getting the code right the first time. Reminds me of the old batch processing systems here in the States where a single mistake might throw a whole, expensive batch. They started inventing language constructs and strategies to make them less likely. The Russians seem to be doing the same, yet with modern hardware and tools. Quite a powerful combination.

“Generally speaking (and knowing perfectly well that there are exceptions) I tend to trust European software way more and I tend to consider american developers to be “hackers” (that’s their term for themselves, not mine!).”

Ouch. We do have shops that focus on quality, even warranting code. That is not the majority by far. 🙁 Most are what Clive Robinson calls “code cutters” that just throw stuff together, hope it works, fix what they could that didn’t, and ship it. Industry focuses on shipping because customers demand it. Bugs get fixed over time. Note that I’ve seen the same thing over in Europe. Example is Windev in France: great tool at boosting productivity, yet has crapload of bugs that each take years to get fixed per users on their forums.

So, American software is only trustworthy if it’s from a shop that focuses on quality. That’s rare as it costs more & takes longer to make. I appreciate your opinion on the Europeans and I plan to get more data on it in the future. I was even considering specific countries over there for subversion-resistant development due to culture maybe having a positive influence on the process.

re Ada, elegance

I understand the feeling, yet disagree. Elegance is usually a sign of good design. Yet, the real world often forces tough tradeoffs for optimal behavior. Scheme was elegant, but Common LISP was more useful in practice. Haskell was more elegant, yet Ocaml provided many of it’s benefits with faster execution & easier training. So, I’ll trade away elegant if it’s practical to not be elegant.

Funny you mention tagged because the first time I saw that I said “wth is wrong with these people? why don’t they just call it what everyone does!?” I thought about rewriting some of that stuff just to make it use the real thing. Then, I looked at the complexity of an Ada compiler and changed my mind.

re Dewar lecture

I’ll try to check it out.

re expectations of OS, developer and user

Good points. These bad assumptions keep recurring.

“To put it bluntly: No matter how many new security regimes we invent, create (probably in C/C++/java …), and deploy, we can and will not stop the security bleeding using the very tools and paradigms that created them in the first place. Stop using C/C++/java – or be hacked. Simple as that.”

Nice. I add “unsafe architectures” while we’re at it.

@ name.withheld

“The two of you represent what I would considered the “most” useful deliberation on programming and security.”

Why thank you! 🙂

“I said, “Go to your computer, locate the cable that is approximately a 1/4″ wide (6mm) that is either black, white, or a light tan. Follow it to the termination point, typically a wall, and immediately pull it out!”

Haha. There was this old method.

“I noticed that Smalltalk is absent in the broad scope of tools for systems programming…”

I left it off on purpose. I wasn’t sure if it was useful for low-level, efficient, systems programming. I did go back and consider it for web applications, yet the web frameworks weren’t so impressive compared to others on the list. So, I just dropped it.

“But, just as I see Java as problematic, (sorry Nick P, I see the whole java eco-system as problematic–even with a JVP–it has created the same bad habits that C was known to do). ”

No need to apologize. I’m not a Java fan. I do like the work on Java processors as they might allow efficient, type-safe system code with object support at instruction level. And half a dozen exist right now unlike both of our projects. I also noted that there’s secure kernels and OS architectures, plus great static checkers for it. Seemed promising as an interim solution.

My plan was to make a core runtime in pure assembler language behind an interface, then map Modula/Oberon to the Java processor bytecode. Oberon to Java & a JVM on Oberon were both already done so this should be easy. Juice also did a Java applet alternative that sent Oberon abstract source tree’s, which were typechecked & compiled locally. That in a capability architecture on a Java processor might be ridiculously robust compared to mainstream alternatives. The result would be a Wirth-like language used to program a relatively safe machine for low level, high level and web programming.

(Note: Ada to JVM has also been done. That would be the next step. Then, I could use an architecture like JX, SPIN, etc with Ada’s or SPARK’s type checking and no VM with huge attack surface.)

“I don’t mean VM in the hardware sense, but in the sense of runtime cores that support some language/application environment.”

It’s fine if it’s easy to analyze. Those language’s VM/runtimes aren’t. They’re too big with designs that allow native code, esp in libraries, to end run the type system. So, I don’t like them either. One exception is Lua as they kept theirs as simple as possible. So simple and consistent it might work without 100+ security holes.

“In engineering there is always the compromise–I don’t care what technology or platform is selected, defined, utilized, or embraced–the architectural decisions that are visible at the “customer” level are always a compromise.”

It sucks. The legacy problem is the biggest of all. I have no easy solution there except to secure what I can and have intrusion analysts carefully watch the rest.

“Don’t get me wrong, I’m a big fan of masturbation, I just have a hard time getting my mind out of my trousers.”

LOL. Most presenters & audience members at DEFCON, Black Hat and RSA are big fans of mental masturbation. So, no worry about standing out too much long as you keep it mental.

Nick P • April 25, 2014 4:38 PM

@ Mr Pragma

“I’m not so sure about assemblers. They are by definition bound to an architecture and I also fail to see the advantage of using yet higher level assemblers. Maybe I’m just a little old style and pragmatic but if that kind of close to the iron is needed I’d rather use C, the meta assembler, and, if needed, hand-optimize its output.”

A secure system is always tied to the architecture. The architecture is where security-enhancing abstraction gaps often break down. You mentioned using C for these parts, yet we’ve already talked about how dangerous it is. It would be nice to have a safe way to code these components that’s low level, efficient, & supports some safety assurances. Cyclone, Popcorn+TALx86, C0 from Verisoft, and so on support low level programming with increased safety. So, that’s why I’m keeping them in mind.

One thing I’m considering is picking an architecture with nice properties, building a safe low-level VM + OS kernel on it, targetting something like Oberon to that, and then building the rest modularly in that typed language. Microsoft’s Verve OS, the Modula 3 SPIN OS, & the Java JX OS make me think it’s doable. My concern here is to essentially raise the assembler up to something safer, then code everything in entire system in that from drivers to apps so they all integrate into same security/integrity scheme. Otherwise, attackers will just hit lowest layer & will have plenty to hit.

“As for LLVM I’m inclined to be quite enchanted. The idea is great, I love it. My only reservation about LLVM is based on the language it’s coded in and consequently the question of reliability and trustworthyness.”

It’s definitely a concern. Might be fixed later. My old method would be to implement the stages in Standard ML, then compile that to executable with FLINT certifying compiler. Results in safe & correct code. Yet, many prefer hand-optimization opportunities and I prefer control over how compiler handles each thing to avoid compiler introducing vulnerabilities.

So, I draw on an old idea: VLISP. It was a rigorously verified Scheme 48 interpreter & compiler for x86, PPC, and ARM. The idea with VLISP would be to implement the compiler stages in SML or Ocaml for algorithmic correctness first, then convert each to VLISP procedures. The builder uses the REPL to interact with the compiler. You could, say, create a compilation profile with certain options for certain modules & tell it to compile. Then, you might review or even edit the results of that before feeding it to next compiler stage. That a LISP gives total access to internal state & allows one to change programming live means more options like these could be created. The use of VLISP means it will be done correctly.

“Usually when I’m confronted with “But C/C++ has gazillions of libraries!” my response is short: “And as many bugs. Thanks, no””

Lol

“Frankly, I consider that approach as yet another example of “Let’s build an even stronger vault door!” (for a thin walled wooden box).”

Hardly. In Habit’s case, they know the low level stuff is where many of the problems are. So, they started with Haskell, built an OS in it (House), and are applying what they learned to a Haskell variant (Habit) designed specifically for low level coding & assurance activities. They also found a sweet spot (H-Layer) for separation of safe and unsafe constructs, while maintaining a protected interface between the two.

If anything, writing most or all code in a such a way boosts many properties at once. OpenBSD you reference has had over 200 security issues. Many are impossible in Haskell, with others maybe being minimized. So, much like Ada or Modula boost safety over C, there are languages with even more advanced type systems trying to take it to next level. Habit/Haskell is one line of inquiry. There’s others, but they’re too alpha quality to name.

“Because they do care about reliability and security for a start. Because they aren’t about politics (GPL, bazar, democracy in engineering, more women in IT, bla bla) but about engineering. Because they damn know what they do and they carefully select who gets writing access and they have a very capable benevolent dictator.”

“And because it’s not at all a coincidence that it was the OpenBSD guys who immediately reacted a) panicked and b) constructive and c) professional to heartbleed. While the rest of the world convened gremia and conferences and discussed and blabla’d the OpenBSD guys reacted properly and did the thing that was to be done.”

These are quite true, though. The attitude, controls, and commitment of the team results in plenty of good quality/security decisions. Their response to Heartbleed was sheer excellence. The dedication was quite obvious with 100+ commits a week. My jaw dropped when I saw all that activity.

“Accordingly the solution isn’t “something even more anal than Ada/Spark” but “something less crappy and error prone than C/C++/java/php/perl”. In other words: We can quite quickly achieve a way, way more secure digital world by coding in Modula, Pascal, Oberon, Ada, Eiffel, Erlang, Ocaml, etc.”

I agree. However, I do want these more anal languages + tools for at least the core kernels, runtimes, and interfaces that underly the “less crappy” languages you mentioned. I also prefer an incremental option: implement critical component using something decent right now, then improve its assurance with the over-the-top methods later if it’s justified. For the core kernels, runtimes, and/or compiler validators, it would seem quite justified to design them with that in mind.

“And yes, let’s enhance formal verifiability for Ada, Oberon, Ocaml and let’s create even better unit test facilities and support, etc.”

Good news is there’s plenty potential. The Ada people are leading with their Ada 2012 and SPARK 2014 standards. Ocaml’s compiler was engineered in stages well enough that a DO-178B tool was written in Ocaml with supposedly easier source to machine code validation. (Manual in DO-178B). Modula’s standard library was formally verified free of certain defects. So, there’s been efforts & I also hope that more come about.

“How about using decent languages instead of trouble generators to produce the 90% of software that is not highly sensitive and to even further enhance the excellent language/tools like Ada and Oberon for critical systems?!”

Exactly!

“IMO those resources/time/abilities would be better put at things like paranoically verifying LLVM (or transcoding it to e.g. Ada), porting a modern version of Oberon to more architectures, implementing ssl in Oberon or Ada, etc. etc.”

It’s a good point I’m debating with myself over. My suggestion to name.withheld was that I port Modula/Oberon to an existing processor that’s safer at instruction level with hardware POLA support (eg object descriptors). Main candidates are a Java processor (without the Java), SAFE processor (tagged & high level), CHERI processor (segmented MIPS), or Itanium (memory keyed). Might then retarget something like SPIN OS, JX architecture, EROS kernel, or Active Oberon System to it. Whole effort would be way less work than a full OS, secure ISA, etc. Then, could build on this medium assurance system using safe language code with protections on. Unsafe code, where necessary, can be isolated in modules/segments and thoroughly analyzed.

“Why? Because the whole chain is rotten. Unix is, the servers are, and the libraries are. And that chain is the massive iceberg of virtually all existing systems.”

I agree. It’s why I’ve mostly avoided UNIX in my discussions as I’m not sure designing a secure UNIX can be done. The UCLA Secure UNIX project found all sorts of issues in it. That’s when you could describe it’s system calls in an academic paper rather than a book. 😉 Microkernel designers and CHERI/Capsicum are doing fine work on securing UNIX-type systems so I’ll leave it to them. I’m looking into system designs that are more assurable. The less work the better because this kind of thing becomes a LOT of work & luck, as you’ve pointed out.

Nick P • April 26, 2014 9:12 PM

@ Wael

“I would like to see someone write an efficient video device driver in PHP or .NET. How about a web application in assembler? Or a microcode snippet in Java?”

I’m not sure what the point of that is but I bet I could do all the above. I’d write a generator of low level assembler or C in each language. Then, I’d write the driver, web app, and microcode in language of your choice with output being something efficient. 😛

” probably call it “C–“”

Already taken.

“I ignored the effects of HW, The OS, the protocols, etc… just to keep focus on the language.”

Haha. The trick is designing them all together to complement each other. This was done in a number of projects with more on the way. Approximate this if it isn’t possible. Once you’re done, it won’t run Windows or Linux apps. Be lucky if it runs any mainstream app. Just means you gotta write a bunch more code. 🙂

Nick P • April 27, 2014 1:09 PM

@ Wael, Mr Pragma, Clive and others

Creators admit UNIX and C were a hoax

https://www.gnu.org/fun/jokes/unix-hoax.html

Posted a version here before but worth sharing again as it’s so good. Funniest thing about it is that it could’ve been true. Wait, is that funny or deeply disturbing given widespread use of UNIX/C? I’ll let you decide.

Nick P • April 27, 2014 10:14 PM

@ David Thornley

Here is an old critique of C++ that you might find interesting. Scroll down the page until you see the bold heading “C++? A critique of C++” It’s a nice essay about the purpose of programming languages, desirable traits, many C++ traits, and whether they help or hinder the process.

One presenting Oberon-2 as a C++ alternative mentioning specifics with example code
http://www.modulaware.com/mdltws.htm

Author of CVSup saying why he choose Modula-3 over C or C++
https://modula3.elegosoft.com/pm3/intro/questions/whym3.html

Ada 95 compared to C++
http://archive.adaic.com/intro/ada-vs-c/ada-vs-c.html

Both have been updated since then, with Ada in 2005 and 2012. Yet, some of the points made still apply. New C++ standard might help with some issues.

Free Pascal lists advantages (short).
http://www.at.freepascal.org/advantage.html

A former Delphi (Pascal RAD) developer on why it won’t die. Implies good things.
http://stevepeacocke.blogspot.com/2013/05/delphi-why-wont-it-just-die.html

Nick P • April 28, 2014 6:40 PM

@ name.withheld

Good hunting. 🙂 The scenario is quite believable. When I based much work on security/separation kernels, I leaned heavily on lessons learned in high assurance evaluations under Orange Book, European standard, and Common Criteria. The requirements involved total lifecycle protection & many assurance activities. However, I noticed that the development & SCM tools themselves were trusted. I criticized this saying much can be bypassed by compromising these. The use of independent evaluation & diverse implementations of tools (esp checkers) helps for sure. Yet, I still saw plenty risk.

My compromise was to leverage my existing cheats. Ideally, the SCM, filesystem, network, IDE’s, distribution, etc would all be A1/EAL7 evaluated if they’re developing a similar grade product. The cheat was to embed high assurance in just a few components: a client-side trusted terminal device, a client side secure network device, a centralized router/firewall/gateway, and a SCM server (or cluster). Except for SCM, each already existed in an A1 product. That saves some effort, eh?

The SCM server is special. It has very minimal functionality with most work being done by untrusted COTS systems. The SCM server just accepts requests, validates them, logs them in append-only file system, and then processes them according to both security policy & SCM functionality (eg scripts). An assured pipeline approach was taken whereby dedicated functions were performed on dedicated, fast devices that booted quickly. SCM would reset a device to a clean state, send a piece of data to it with an order to perform a function, over a safe interface of course, and then store the results with some metadata in its append-only storage. This scheme prevents many attacks by design, while making others easier to detect & recover from.

Oh, I forgot to mention that a regular Windows or UNIX system was used for each developer with corresponding benefits. Completed code was sent through a guard (even a simple Pump) to the trusted client. Two screens are used to make a visual comparison easier. Per security policy, SCM only accepts code from trusted device & no Internet access is allowed to it (or its helpers). Signed releases are obtained either manually over standard media or automatically via transmission over data diode to untrusted server. That server is optionally public facing for app or data dissemination. Most devices involved are small, cheap PC’s so justify using so many of them. Today, it would be PCI card, pico-ITX, or 1U type systems.

Might have solved your problem.

@ Clive

“One of the problems with languages that do a lot of “in the background” activities such as garbage collection, bounds checking , etc is it provides signals that can be both recognisable and regular to the software flow. Which makes for reliable triger points for amongst other things DPA.”

It’s definitely true as I criticized Freenet for using Java both due to attack surface & how it obscures covert channels. Of course, one can use a safer language & still assess covert flows in a number of ways. If language basically just introduces checks, one can create a more detailed view that shows all code including checks & calls to any runtime. If using structured programming, the analysis can be done quite easily. There’s still issues such as out of order execution, caching, etc.

This leads me to another possibility. There is existing work in languages and runtimes designed to detect, prevent or mitigate covert channels of various kinds from software to hardware. Quite a few methods for storage and timing channels in sequential code. At least two for concurrent. Such techniques can be mapped to whatever safer language is to be used. Tools would analyze code using such a framework & produce a report of potential covert channels in the code. The developer could then take steps from there. Seems straightforward enough.