The Security of Various Programming Languages

Interesting research on the security of code written in different programming languages. We don't know whether the security is a result of inherent properties of the language, or the relative skill of the typical programmers of that language.

The report.

EDITED TO ADD (5/14): Direct link to The report.

Posted on April 23, 2014 at 7:53 AM • 82 Comments

Comments

ThierryApril 23, 2014 8:14 AM

Sadly this report only mentions languages for Web sites and not for general purpose development. OpenSSL + C == Heartbleed...

Also the figures are too similar to be significant. And the PHP score is better than the Java one, while PHP does not check anything and allow mixing data of any kind, until something weird happens.

I would not trust that report that much. But there is a real need for good reports on the subject.

BenniApril 23, 2014 8:25 AM

Can some expert tell me what this openssl code is for
I don't know any ASM, but it seems to be some function caller for win 32 which was also compiled under unix:


http://freshbsd.org/commit/openbsd/f868fc6f39a2c45a6c2bab70addc92525d467904

So it turns out that libcrypto on i386 platforms, unconditionaly compiles this
little gem called OPENSSL_indirect_call(), supposedly to be ``handy under
Win32''.

In my view, this is a free-win ROP entry point. Why try and return to libc
when you can return to libcrypto with an easy to use interface?

Better not give that much attack surface, and remove this undocumented
entry point.

ok beck@ tedu@
+0 -39 lib/libssl/src/crypto/x86cpuid.pl
+0 -39 1 file
diff --git a/lib/libssl/src/crypto/x86cpuid.pl b/lib/libssl/src/crypto/x86cpuid.pl
index c7a57a3..169036d 100644
--- a/lib/libssl/src/crypto/x86cpuid.pl
+++ b/lib/libssl/src/crypto/x86cpuid.pl
@@ -257,45 +257,6 @@ for (@ARGV) { $sse2=1 if (/-DOPENSSL_IA32_SSE2/); }
&ret ();
&function_end_B("OPENSSL_atomic_add");

-# This function can become handy under Win32 in situations when
-# we don't know which calling convention, __stdcall or __cdecl(*),
-# indirect callee is using. In C it can be deployed as
-#
-#ifdef OPENSSL_CPUID_OBJ
-# type OPENSSL_indirect_call(void *f,...);
-# ...
-# OPENSSL_indirect_call(func,[up to $max arguments]);
-#endif
-#
-# (*) it's designed to work even for __fastcall if number of
-# arguments is 1 or 2!
-&function_begin_B("OPENSSL_indirect_call");
- {
- my ($max,$i)=(7,); # $max has to be chosen as 4*n-1
- # in order to preserve eventual
- # stack alignment
- &push ("ebp");
- &mov ("ebp","esp");
- &sub ("esp",$max*4);
- &mov ("ecx",&DWP(12,"ebp"));
- &mov (&DWP(0,"esp"),"ecx");
- &mov ("edx",&DWP(16,"ebp"));
- &mov (&DWP(4,"esp"),"edx");
- for($i=2;$i - {
- # Some copies will be redundant/bogus...
- &mov ("eax",&DWP(12+$i*4,"ebp"));
- &mov (&DWP(0+$i*4,"esp"),"eax");
- }
- &call_ptr (&DWP(8,"ebp"));# make the call...
- &mov ("esp","ebp"); # ... and just restore the stack pointer
- # without paying attention to what we called,
- # (__cdecl *func) or (__stdcall *one).
- &pop ("ebp");
- &ret ();
- }
-&function_end_B("OPENSSL_indirect_call");
-
&function_begin_B("OPENSSL_ia32_rdrand");
&mov ("ecx",8);
&set_label("loop");
Raw diff

JApril 23, 2014 8:30 AM

The article doesn't seem to match up with the infographic:

The bottom of the spectrum, or the most "secure," also showed no significant difference between languages with the lowest averages of vulnerabilities per slot. Perl was observed as having 7 vulnerabilities per slot. ColdFusion was found to have the fewest with an average of 6.

And yet the circles at the top of the article show ColdFusion with 7 and Perl with 6. I haven't looked at the report itself to see which is actually correct.

M WelinderApril 23, 2014 9:02 AM

Really?

As far as I know, no program written for a formal Turing machine has ever been implicated in any breach. Programs as automatically protected against a range of systemic risks, such as buffer overflows.

And a fat load of good that does anyone in the real world.

JoeApril 23, 2014 9:14 AM

One has to take this with a grain of salt. Coldfusion is probably the most insecure web platform of all, hacking-wise. And it sure likes to crash a lot, not to mention all the SQL injection issues. Typed languages offer more protection against doing stupid things, unless the stupidity is encapsulated in buffer move macros and functions (Heartbleep, I mean you!). Obviously Facebook has been bitten too many times by PHP and has now put their typed version of the language out there for the public to use. And did anyone consider that a quasi-compiled web platform (JSP, .NET) might be safer than a purely interpreted language (Perl, PHP)? I don't think this study was done with much thought.

MattApril 23, 2014 9:15 AM

How are they sure they aren't measuring the efficacy of their tools for finding bugs written in different languages?

RSaundersApril 23, 2014 9:53 AM

It's too bad you can't program web sites in FORTRAN or PL/1. No pesky, error-prone pointers in FORTRAN; and PL/1 on Multics used hardware to make it impossible for programmers to code the buffer overrun vulnerability that enables Heartbleed in the early 1970s (coming up on 50 years!).

There was cruft then as there is cruft now. OpenSSL is well known for its cruft, and the LibreSSL people have been raising money to make a clean replacement for years.

The true problem is that people accept too much cruft in their world. Users can't help it, to them software is sufficiently-advanced-technology. Developers and their managers need to hold themselves to a higher standard, like serious professionals in other fields.

Eric WilsonApril 23, 2014 10:26 AM

So the report is based on 30,000 websites who were selected on the basis that they were clients of WhiteHat Sentinel?

Even without that bit of information it was pretty obvious that this report was heavily biased towards large enterprise companies just by looking at their breakdown of languages by popularity.

Ian WoollardApril 23, 2014 10:58 AM

Pretty sure most of the common vulnerabilities are language specific, at least if you take a very wide definition of language (for example html is a language susceptible to Cross-Site Request Forgery attacks.)

The idea that programmers are going to be uniformly smart enough to correctly plug the holes in languages is most of the problem.

Basically, if you assume people don't make mistakes, you're going to have a hard time.

Douglas KnightApril 23, 2014 11:57 AM

These kinds of vulnerabilities might be the fault of the library, but how could XSS or SQL injection be the fault of the language?

yesmeApril 23, 2014 11:58 AM

Well, these are my 2cents.

Wether a language sucks or not depends IMO on the following conditions:

- Be simple and do what you expect it to do (sorry C++)
- Clear and non cryptical syntax (again sorry C++)
- Garbage Collected by default (euh... sorry C++ and C)
- Productive (euh... sorry C++)
- Easy to learn (euh... never mind)

Of course Bjarne S. has a different view of the language. In this interview he explains the real reason for developing C++.

But the recently discovered holes (actually enlarged Boeing 747 hangar doors) in OpenSSL and GnuTLS could only have happened in C and C++.

That is a fact.

AnuraApril 23, 2014 12:08 PM

These languages don't really have any difference in protection against XSS vulnerabilities; that's a problem of taking unsanitized input and writing it directly to the page. All of these languages have frameworks that make that unnecessary in most cases, but people end up writing HTML directly at least some of the time and they rarely sanitize input while doing so.

Things like SQL injections can be prevented by using safe methods to access the database which are usually available (e.g. parameterized queries, ORM), but all of them provide the ability to write direct SQL and people build SQL statements as strings with unsanitized user input.

There are also Cross Site Request Forgeries, which some frameworks have built in controls to protect against, but usually do not do by default. It's a matter of adding a random token as a hidden input that is tied to the session to prevent someone from forging a form.

I don't think this really measures the security of the languages themselves, so much as it measures the developers themselves.

Caleb CushingApril 23, 2014 1:09 PM

I personally believe that the problem is neither language nor truly relative skill... it's that the learning materials don't teach in a secure by default manner. Often they teach you insecure practices as they are the easiest. In fact I feel there are very few programming books at all that teach you how to program both securily (such as avoiding heartbleed) and security features (such as Access control), and this results in a large bulk of code being insecure.

AlonApril 23, 2014 1:31 PM

I couldn't really trust any results from the article based on the obviously false statements they have made. They refer to ASP, Java, and .NET as "modern" while PHP, perl, and ColdFusion have "been around for decades", even though Java appeared the same year as PHP and ColdFusion (1995), and ASP was released in 1996. Moreover, .NET is a framework, not a programming language, and the distribution of languages makes no sense. Where is C? C++? Python? Ruby on Rails?

AnuraApril 23, 2014 1:38 PM

@Caleb Cushing

I think it's a little of all three. When it comes to things like SQL injection, the tools to do things right are there, and it's the fact that most language tutorials teach you the obsolete and insecure methods of running SQL statements. However, for things like CSRF, I do think it's a language problem as the language makes you do extra work to protect against it. It's also education, because if you have to do extra work, someone needs to teach you that.

With XSS, some people will at some point have to directly write HTML to the page based on user input. While frameworks can take care of most of it, there are going to be some circumstances where the tools provided are insufficient, and the problem is that the language features that write to the page don't sanitize the input, and you usually have to call a separate function to do so. If instead of ASP.NET having Response.Write and having to call HttpServerUtility.HtmlEncode as well, we had Response.WriteText that encoded the text and Response.WriteRaw that didn't, then you would force people to consider which one they wanted to use.

There is also the problem of people who know how to do things right, but get lazy or pressured for time and start making mistakes. This is why we need languages and frameworks to be designed to make the safe methods both the primary tools at both the higher and lower levels. Hell, there can even be warnings for unsafe methods for compiled languages like .NET and Java.

AnuraApril 23, 2014 1:40 PM

@Alon

This is focused entirely on the most popular web programming languages (and .NET probably includes both VB and C#).

LApril 23, 2014 1:47 PM

The article seems to only consider web-related languages. Web is a big thing today, but not everything, so talking about any native language is a little OT, but anyway...

Putting together C and C++, especially the newer C++11/14 shows that you do not know the language.

Sure it's complex. But they are not the same.

C++ needs stricter coding rules, but I still consider it the best option, you can go low-level if you need it, there is not garbage collector, which is bad for any formal analysis of memory, is hardly predictable and slow, doesn't have a whole virtual machine and doesn't have the "everything is virtual" mentality. C++ compiler are the most advanced and developed today, too.

Those holes could only have happened in C, because both OpenSSL and GnuTLS are coded in C, because gotos in C++ are not so necessary anymore, because in C++ everybody uses vectors or strings which already provide .length() functionality, so you don't actually have to reimplement it every time, because in C++ whenever you are using malloc/free you are most probably wrong, because MACROS should only be used as header guards in C++... because... C++ is not C.

If you think they are the same, do not write C++ code, it will be your worst thing ever.

Also, compilers have gotten really good, and we have a lot of tools for static analysis of C and C++ code. But people should use those...otherwise it's pointless. Simply compiling with -Weverything can tell you a real lot, and help you improve.
The TLS goto bugs would have been really easy to spot with just a "dead code elimination" warning... you know, the one that says "this code will never be executed"...


So you have a huge mass of unchecked, barely maintained macro-ridden code, with a style that has nothing to do with C++... and yet C++ is the same.

Programming correctly in C++ is harder than in java, ok. Still, no language can be idiot-proof. Idiots are always smarter. C++ used correctly takes away all the bad things from C.

Maybe something else is still safer, but C++ is NOT C.

Snarki, child of LokiApril 23, 2014 2:20 PM

I can confidently predict that ZERO security holes will be found in APL.

yesmeApril 23, 2014 2:25 PM

@L, the title suggests languages in general, the article is indeed about the web.

The funny thing is that everyone talks about C++11 these days as if it is some magic bullet. The reality however is that every library is still written in the old stuff so you need to know the whole lot. That's the problem with backwards compatibility.

"C++ used correctly takes away all the bad things from C."

The problem here is "used correctly". But that's als the case with C.

As a side note, the OpenBSD guys have the OpenSSL fork now working with -Wall -Werror. (btw, dead code detection flag doesn't work with GCC)

My favorite systems language however is Go. Close to C but without the pitfalls.

TLApril 23, 2014 3:43 PM

@yesme "My favorite systems language however is Go. Close to C but without the pitfalls."

I like C because of what it enables me to do, not the power that it takes away.

So many other languages are defined subtractively from C, taking away pointers, or goto statements, or explicit memory management. That means you have *less* power to control the machine.

If I was a surgeon, I wouldn't want to wear oven mitts to perform an operation, so why would I want to use a computer language that blunts my capacity to define how the computer works?

AnuraApril 23, 2014 4:01 PM

@L

Can you give me an example of a large C++ application that doesn't use raw pointers or arrays? I will ignore the parameters of main being (int argc, char **argv) instead of (std::vector<std::string>).

@TL

The surgeon analogy is flawed as higher level languages generally take less effort to accomplish the same task without making a mistake. What exactly are you coding where raw pointers are preferable over a bounds checked, type-safe container?

Shawn SmithApril 23, 2014 7:50 PM

@Anura,

The first thing that pops into my head as to why I would use raw pointers is when working with display framebuffers on a ssssslllllloooooooowwwwww processor or memory-mapped I/O ports. And in those cases, why not go all out and move down to assembly? But other than that, yeah, I've got nothing.

ottoApril 23, 2014 8:04 PM

They only mentioned PHP in the beginning of the article, and never again. Really sticks out as kinda lazy.

PHP has a vibrant community, and excellent documentation. I use it for sysadmin production tasks (it's multi-platform) and on embedded systems. It's fast to make changes (no compile or JVM) and easy to read, with control structures like C. Untyped languages make it easier to get good code out the door faster.

You have to build security into your application from the beginning. It's not a language attribute. The responsibility of the programming team is to design, code and test their application to survive in a hostile environment.

Nick PApril 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! :)

Richard SchwartzApril 23, 2014 9:08 PM

Is it just me, or does anyone else have a problem with research that appears not to understand the difference between a language and a framework?

Nick PApril 23, 2014 9:28 PM

The Study

The choice of .NET, Java, PHP, and ASP.net are good as they'll represent most web applications. Coldfusion is OK as there's at least a lot of legacy systems running it. The fact that they chose Perl instead of Ruby (i.e. Rails) is confusing as I almost never hear of a web app being written in Perl, although Rails became a tiny industry. Although, the Movable Type system that powers Bruce's blog is Perl-based.

The overall vulnerability ratio along with their explanation (attack surface) seem accurate. It's unsurprising that there wasn't much difference between the major platforms because *they're about the same in terms of features and how they implement them.* I'd like to see a similar analysis of web apps in Erlang, Ocaml, Haskell, Ada, or LISP. They handle things quite different & have different levels of effort in safety/security. Of course, there are technologies designed specifically for secure web applications which are covered in above essay.

SQL injection, Cross-site scripting, and cross-site request forgery are still a big problem despite proven methods of dealing with them that aren't such a pain. Problem must be in language, platform, libraries and/or processes. These issues simply shouldn't be happening given what we know about preventing them.

Responses to individual commenters

@ Benni

That does look suspicious as heck. That it's a bunch of assembler would make a mistake both easier to hide & look like programmer error.

@ Weilinder

"As far as I know, no program written for a formal Turing machine has ever been implicated in any breach."

Far as I know, no formal Turing machine has ever been implemented and practical at the same time. I'm glad you mentioned it, though, as I found a bunch of interesting research leveraging Turing machines for security. All this time hearing about the concept I never knew how much better it was for real security vs common machines!

@ Ian Woollard

Good point. Pushing more worries on a programmer while assuming they'll do things right isn't a good way to do things.

@ Neal Lester

It was a good read and a sound argument. I looked at author's name after reading the article so it was a pleasant conclusion to see it was none other than the inventer of a good language. He doesn't just preach a theory, he put it into practice. :)

@ Douglas Knight

"These kinds of vulnerabilities might be the fault of the library, but how could XSS or SQL injection be the fault of the language?"

See my above post on how certain languages' design decisions make many errors easy to prevent.

@ Anura

"I don't think this really measures the security of the languages themselves, so much as it measures the developers themselves."

I agree mostly. Although, naturally I'm also inclined to blame languages that make mistakes easier. We all had this discussion re system programming recently. Many of same points apply to secure web programming.

@ Caleb

"I personally believe that the problem is neither language nor truly relative skill... it's that the learning materials don't teach in a secure by default manner. "

It's really the language/platform, Caleb. In some I posted above, you can practically throw a web application together while being sure it doesn't have all kinds of problems. That someone has to pause with concern for every function they write to accomplish the same thing says their tool is inferior. If it can be automated away, it should be.

@ L

"Putting together C and C++, especially the newer C++11/14 shows that you do not know the language."

"Programming correctly in C++ is harder than in java, ok. Still, no language can be idiot-proof. Idiots are always smarter. C++ used correctly takes away all the bad things from C."

Most C++ code isn't the newest one so it's an unfair statement. That said, while there are many differences, C and C++ share many of the same risks from a security point of view. Particularly, many of the most common operations must be scrutinized to avoid code injections. A previous discussion on this blog covered many languages that are type and memory safe by default while allowing high performance code. Two were used to write operating systems, microcontrollers, etc. So, putting C & C++ into the same category, while labeling them bad for security, makes sense to me. Compared to a language like Ada or PL/I, C++ is just turd polishing of C.

@ snarki

"I can confidently predict that ZERO security holes will be found in APL."

I'm placing a bet on a code injection in the interpreter using a failed array bounds check. Just because it would be ironic and hilarious. ;)

@ otto

Check out Quercus's implementation of PHP in Java. Combines best of both world's. I kept it in my archives in case I was ever forced to use PHP I might avoid some of its security problems. "And trade them for Java's" you might say? Yeah, it's why decided against both but it's nice to have a safer implementation of PHP with access to Java libraries.

@ Richard Schwartz

"Is it just me, or does anyone else have a problem with research that appears not to understand the difference between a language and a framework?"

Yeah, they kind of go hand in hand in web app development. A language with one might have shoddy security, while another framework provides excellent security. It's why I mentioned both in my essay above. Analyzing one without the other makes little sense.

AnuraApril 24, 2014 3:11 AM

@Nick P

I agree mostly. Although, naturally I'm also inclined to blame languages that make mistakes easier. We all had this discussion re system programming recently. Many of same points apply to secure web programming.

Naturally the same things apply, however in this case I think the frameworks and tools available are fairly even across the languages; .NET has pretty good tools available and there are good frameworks for Java and PHP as well. This is why I say that most of the differences you see between these languages in this particular test is going to be more about the developers than the languages themselves.

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.

AutolykosApril 24, 2014 5:23 AM

I agree that C makes it unnecessarily hard to write safe code. That argument, however, only translates to C++ if the guy writing the code still uses C++ as he would use C. But there's no sane reason to. Classes in C++ increase safety a lot (especially if you are consequent about getters/setters and RAII) and hardly cost any performance at all (unless you go heavy on the virtual or write poor C'tors, D'tors and assignment operators). Most stuff in the STL is safe and convenient to use, while still being at least as fast as you could expect it to be if you write it yourself (unless you're a true ASM whiz). If you ever have a raw pointer/array in any but the innermost and best encapsulated C++ code, you're doing it wrong.

So the main argument against C++ is that it doesn't *prevent* you from writing bad code if you really want to. But I don't think a language should - compilers that think they are smarter than the programmer are a serious pain in the lower backside and will inevitably result in programmers trying to outwit the compiler once they feel the need to use the "unsafe" parts (you can see that a lot with PASCAL and Java).

Mr. PragmaApril 24, 2014 5:30 AM

That "report" starts by mentioning which languages are the most used.
Which basically comes down to saying that these languages don't have security or safety in their mind in the first place (and yes, as if to shout out "we do not really know what we're talking about" that company mixes up languages and frameworks on top of it).

But let's look at it because actually the raison d'etre of a language *does* provide valuable hints at, among others, safety and security.

Nota bene: I'll put C and C++ into one box and so I will do with Pascal and Modula, too. In both cases the languages are quite closely related and in fact the latter was inspired (or even guided) theoretically as well as practically by the former.

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. But there's a but: That does include that C was meant to be an elegant super- and meta-assembler.
I think that C still is a language of choice for low level routines close to hardware. Sure enough, though, C has not been designed for nor is it adequate for general programming, particularly when considering safety and security (which wasn't a big issue for K&R. At that time pretty everything was filled with trust and differentiating between different users and root was almost more than was considered needed).

Funnily Pascal which was developed at roughly the same time and for quite similar purposes, albeit more implicitly, took a very different approach. Where "power" was paramount - and natural - for K&R, "safety" (in todays lingo) was paramount for Wirth. While some say that Wirths main reason was simplicity (with safety just a consequence), based on what his later work tells about Wirth, safety *was* important to Wirth, too; maybe not expressly but sure enough, safety (well, what we call safety today) *was* important to Wirth. And Wirth *did* know that his approach carried a hefty price tag concerning Pascals usability for low level systems programming ... and he went on to create Modula which was way better suited without giving up Pascals advantages.

And like that it still is today. Pascal, Modula, Oberon ... up to Ada and, to a degree, the strange cousin Eiffel do value safety highly but implemented different approaches to low-level close the the iron programming.
And C/C++ and their many offspring still don't care too much about safety. 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.

*If* this world were full of professional and professionally trained developers, C/C++ might be good solutions. Millions of bugs and eruptions like heartbleed, or openssl in general, however, very strongly suggest that this world has to do with a very considerable part of less capable developers.
And btw: openssl is what the C/C++ developers that we happen to have around create when they expressly work on security sensitive stuff ...

Java was created to run on anything that holds still long enough to inject a vm. If java had security and safety in mind (frankly, I doubt it, no matter what they tell me) then they relied mainly on bureaucracy to achieve it (Yes, I'm somewhat biased but then, who could seriously demand - and based on what? - to consider java anything but a funny experiment gone awry?) The mere fact of java being in Oracles hands (and the way they handled it) tells me loud enough to avoid java fervently.

On a sidenote: I sometimes wonder whether that whole language thing also tels a lot about usa and europe. In Europe the Wirth languages were created, OCaml, Erlang, and Ada (yes, right, Ada. It was ordered by the us dod but designed by a frenchman) while the usa has C and a bunch of commercial thingies like java, [whatever]script, etc. And no, I do not mean to imply any judgement; it merely strikes me as different cultures (or culture at all *g) like in France, Germany, Suisse, or in Russia vs. in usa, canada using rather different approaches following rather different criteria and wightings. I personally rest very strongly in the European camp although I profoundly respect K&R and praise Tucker Taft et al. for what they have done with and for Ada (and for respecting some basic "holy credos" of J. Ichbiah in the first place).

My personal preference is Modula/Oberon (although compiler support is thin and for few architectures only) and Ada 2005 (yes, I *love* 2012). I have to (and want) to "confess", though that I really like Adas very hands down practical approach and support for C.

Is language a decisive criteria for safety and security in the world we live in (as opposed to a heaven with professional C developers): You bet!
When developing in Ada or Oberon a bug is a strange creature and a security flaw is bad design and rare. When developing in C I spent eternities with a debugger. Not because I'm a lousy coder but because safety and reliability meant a lot even when developing in C (and unit tests were not yet standard procedure).

I am, btw, not a yota less productive or fast in Ada or Modula or Oberon than in C or C++, quite the contrary. 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). I wouldn't think in terms of security of Python or, more generally, scripting, but one can create quite reliable utilities. And it needn't be expressly secure (for that there is Ada or Modula etc.) but it mustn't be a trouble ticket generator like Perl neither ...

I hope I didn't bore you but I'm concerned with those questions since more than a decade and I was and am under pressure to be productive yet deliver reliable and secure products. So I thought you might be interested in some of my thoughts.

Mr. PragmaApril 24, 2014 5:44 AM

Oh, and btw:

Would you kindly stop to insult us with the C11 and similar arguments?

Fact is that gazillions of lines of - often security relevant code (-> openssl) - are written in not even C99 but, in fact, old K&R (plus some funny compiler dialects (-> pragmas)).

Similarly the argument of tools, discipline and whatnot are missing the point. C had decades to become more safe, in design as well as in practical use. Unfortunately, for some weird out of this world reason (because, listening to the C/C++ faction, each one of them seems to produce close to perfect, unit tested, statically analyzed and whatnot code) the sad fact is that very much - if not the vast majority - of C and C++ code is full of crap.

So, sorry, using C/C++ [current standard plus bla] is *not* the answer.

(Oh, and yes, offer me your other approach, too, namely kindly dare to tell me that I simply don't know what I'm talking about. As a matter of fact I did teach C and C++. I didn't throw away tens of years of language proficiency and more than 10.000 $ worth of tools for the fun of it but because I *had* to.)

LApril 24, 2014 7:34 AM

Calm down, I never said that you can't write bad things in C++, and I never put it against ada, erlang or any other language.
I simply said that IMHO C and C++ are structurally different languages. Even more if you consider pre-C99 and post-C++11.

Your argument is: today a lot of software is written in pre-C99, therefore C++ sucks. 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.

Sure you can write C and C++ code with the same assembly, but I still think a correct c++ is way safer than a correct c. Of course having bad programmers will mean non-maintainable code and bugs in any language. New tools *do* help. But people need to use them. otherwise it's like writing perfectly safe code with a (known) buggy compiler...

Still, for any (opensouce) big project today C/C++ is the only choice, since that's what people know the most.

Purely functional languages are great and extremely safe, but you reach a fraction of developers. You must also take that into account: opensource works because lots of people can edit the code. Write in ada if you want. It will be great code. But with one or two contributors. Your project will take longer to develop, fix, will be harder to find contributors and maintainers.

It's all about tradeoffs, IMHO c++ with a good maintainer is a good tradeoff. That's all I'm saying. I never compared C++ to anything else than C, btw.

Peter BoughtonApril 24, 2014 8:52 AM

Joe wrote:

>Coldfusion is probably the most insecure web platform of all, hacking-wise.

I'm not an Adobe fan, but I'm pretty sure EVERY CF attack that has been reported in the past 24 months was due to an UNPATCHED server - that is, Adobe had already released the fix, but the server admins hadn't bothered to apply it.

(Which isn't to say some of the issues weren't ones that never should have existed in the first place, but it's unfair to entirely blame CF/Adobe.)


>not to mention all the SQL injection issues

PEBKAC

The CFML language provides the tools necessary to prevent SQL injection.

The issue is primarily bad programmers, bad programming practices, and perhaps a touch of Adobe's reluctance/inability to properly educate developers.

Nick PApril 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. :)

Mr. PragmaApril 24, 2014 10:22 AM

Nick P (April 24, 2014 9:24 AM)

"Back in the day, it made plenty of sense to make something like C at least."

While this is only a small remark, seemingly not deserving further attention, I see more there.

First, of course, a cross architecture meta-assembler made lots of sense and was - and still is in certain areas - very useful.

Also, funnily, I find myself using C again when doing jobs close to hardware. Obviously Modula is perfectly capable to address that area, too, as has been proven by Wirths OS. Actually, however, I think it's some kind of "mindset" issue. I *do* value Modula, Oberon, and Ada highly but I can't help but associate those with Program development - and C with "close to the iron stuff". It just feels more natural for me to do in C. Speaking in Wirth terms were he has the "System" module I go C directly.
And while it always felt strange to trace, say, some client interface application in the debugger, I almost feel "Hell, why isn't the compiler and editor right in the debugger environment?" when, say, coding some low level stuff on a microcontroller; it's just natural there to think and work in bits and registers.


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

True. 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. And in a way they even day it openly. "We want a better 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. If one *could* one would end with sth. like Modula or Ada but with C like notation (e.g. braces instead of begin ... end).
Just read their discussions. Yes, for instance, D offers DbC but you'll find that a (by heart) C++ programmer (and that's what most of them are) has a quite different approach to DbC than and Ada programmer. To put it losely, while DbC was a much welcomed and dearly missed (by many) in Ada (2012) it's hardly more than a "cheap insurance" concept or, worse, a pimped up assert() for most D guys.

But granted, using D I felt way better than when dealing with C++ and all it's, uhum, cousins (Have a look at Cyclone! Nice intention, typical C/C++ look approach).

"Americans invented the first ..."

Oh well, there could be lots of debate there (Germans, for instance, might deservedly bring up Mr. Zuse) but that wasn't my point anyway.

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?) the Russian are very favourably 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).
The French have some kind of "silicon valley" with INRIA and Germans probably have a more engineering like approach to code.

To put it in a funny looking way: One very often hears "it's fun!" in software developer circles. Well, you won't lose money placing bets that the ones saying that tend to be americans ...
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!). To summarize it bluntly I would assume that code from the usa has either been hacked for fun or hacked under marketing pressure. Apologies if anyone feels offended.

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

Maybe you'll laugh at me but the only reason I'm not purely Ada but am rather almost fighting to use Oberon or Modula is elegance. I consider elegance and beauty to be trustworthy indicators of quality (which might also explain my love for Python for scripting) and I feel that Ada unfortunately feels like considerably less elegant and kind of nailed and hammered together. One reason for that might be Adas tendency to invent new names like "tagged" for well understood paradigms and structures. otoh, Ichbiah had a strike of genius when he invented the tick features.

"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. :)"

Yes, sir. That was well put.

I strongly suggest Mr. Dewar's "lecture" (actually it's more a casual style talk albeit with lots of depth and content) at MIT (http://www.youtube.com/watch?v=0yXwnk8Cr0c) to anyone seriously interested in solid software development.

name.withheld.for.obvious.reasonsApril 24, 2014 1:49 PM

@ Nick P, Pragma

The two of you represent what I would considered the "most" useful deliberation on programming and security. Notice, I didn't phrase it as secure programming--that's an oxymoron. Secure programming is not necessarily a centrality of any "secure" system. Recently a friend asked me if he was a risk for subjugation via a form on some web site...

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!"

There--now you've secured your system. (And still, there is a, albeit highly unlikely, risk of subversion.)

I noticed that Smalltalk is absent in the broad scope of tools for systems programming...there was an effort over a decade ago to get Smalltalk on embedded computing platform. 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). Smalltalk shares what I see as problematic with VM cores. I don't mean VM in the hardware sense, but in the sense of runtime cores that support some language/application environment.

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. Why, just as Bruce has said and is his mantra--there is no absolute security.
Expectations almost never match reality--I call it "Engineering Relativity".

I don't have a "solution" for a problem that I and most of my colleagues didn't create--or even know about. This kind of architectural hijacking by entities that represent "institutional" trust is a beast I didn't envision battling as a young child embracing the religion of science as the the only true path. What a fool was I? What I do know, we are getting nowhere--the amount of progress that represents are "re-balancing" is nothing more than intellectual masturbation. 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.

A year later and the broad scope of security issues that we KNOW about are still at issue...I need to go and read a EULA to remind me of the source of the problem. My rant for the week...

Mr. PragmaApril 24, 2014 5:25 PM

I'd like to add a point.

It's about barriers and about them being mis-designed and misplaced.

Security - at least from one perspective - can be described as denying an attacker the means to attack (which again can be broken down into extending the time needed for attack, lowering the probability of success etc. but let's stay simple here).
So, a vulnerability is a means of (illegitimate) access and so is, say, (in a way) a properly secured and locked door with a window next to it that is made from soft wood and that lacks any security measures.

Accordingly, one way to "create" security is to *not* create weaknesses that offer means of illegitimate access.

Who is the foe and what is an attack? An attack can be described as an improper way of gaining access and a foe is anyone who employs methods to improperly gain access.
But what if improper access is gained without malice intent? What if, stupid example, my trousers have a hole and I'm losing money while walking? What if a woman undresses for bed and doesn't properly block any means of sight into the room?

Now, we're pretty close to programmers - unintentionally - creating weaknesses which sooner or later will be used as means for improper access (or operations, or ...).

Obviously, the woman should close the curtain properly and fully and so should the programmer. So why does neither of them always, reliably and fully? Is it the womans kink to be observed while undressing? Is it the programmers rational decision to create backdoors? Quite probably not - yet they do exactly that.

Or, to put it more bluntly, there is a trust problem namely, the problem to trust programmers that they are willing and capable to really fully understand each and every of their lines of code and to invest no matter what energy and means to code perfectly. Are they willing to do that? Quite possibly usually, yes. Are they capable to do that? Quite obviously frighteningly often, no.

To cut it short, an OS expecting the user (or program) to behave correctly, reliably and responsibly, got something very wrong. Maybe that approach would on another planet (like the one where those C/C++ developers who think they can and do create good code live *g).

Similarly, a language designer expecting the user, the developer, to behave correctly, reliably and responsibly, got something very wrong.
Realistically - and having profoundly understood some human properties - a language designer has to assume that his "users" can - and will - engage in improper use of his language.

Finally (ignoring more steps in between) a developer expecting his users to behave correctly, reliably and responsibly, got something very wrong.
Realistically - and having profoundly understood some human properties - a developer has to assume that his "users" can - and will - engage in improper use or even abuse of his program - not rarely even with malice intent.

Accordingly, developers have to base their work on the assumption that, be it with malice intention or just incompetence or due to other factors (and there are many with humans ...), their users (and often even the users/clients of their users; just think -> server) can - and *will* misuse or even abuse their software.
And so do Operating Systems. To achieve any not insignificant level of safety, reliability and security, their creators have to base their work on the assumption ... can - and *will* misuse or even abuse their software.
And finally, so do language designers - and the wiser ones did. They have to base their work on the assumption ... can - and *will* misuse or even abuse their language.

Last but not least we should considerably extend our understanding by recognizing and acting accordingly. Usually we still think of a security problem in term of evil, dark dressed attackers. Actually though, a very considerable part of security problems do not arise out of malicious attacks but are based on negligence, easy going, opportunity; accordingly they can not be avoided by building ever stronger vault doors or, in computer terms, by ever stricter security regimes, by adding CAP facilities on top on MAC, etc. - but by *additionally* avoiding the unintentional creation of, in effect, back doors.

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.

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

Mr. PragmaApril 25, 2014 7:10 AM

@name.withheld

Thank you ;)

@Nick.P

Ad Assemblers, LLVM:

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.

There's actually more to it (well, in *my* head, that is. ymmv). My rule of thumb is that actually we humans are way better in optimizing than computers; they otoh are just great in reliably and (with anal precision) doing what we humans tend to do not so well (like finding 10.000 occurrences of a string and not missing 1). I remember hand-optimizing the assembler output of the C compilers for some routines and achieving an improvement I'd rather not tell you so as to not be considered bragging. In simple words: We humans, at least often *can* very much optimize. But then, that's rarely justified and the mere decision what and where to optimize is a good level of expertise and craftsmanchip.

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.

But, no doubt, those guys have had a very striking and brilliant idea and along the path they've made some very good and bright decisions (the interim-code, the dual exe and interpreted offer, and some more and all that well thought out down to "details" like data types and very flexible). Praised be they!


Ad "D, Cyclone, and Ironclad C++":

Well, for a starter, D still has rather limited library support and that's the or at least a major holy grail in the C/C++ world (explaining in part its slow take up).
Find me a C/C++ guy who doesn't blow the "C/C++ has the most libraries available" fanfare when looking at language alternatives and I show you a man that can still be shown the light and whose brain hasn't turned into stone yet *g

And btw. I think, the libraries point is extremely short sighted and exaggerated.
For (at least) 2 reasons:
- Modula, Oberon, Ada, Eiffel and particularly Pascal certainly don't arrive naked. They are stuffed with quite well sized libraries and on top usually allow you to use C libraries, too

- What's the worth of a gazillion of libraries if many of them are written by "have fun!" 14 years old experimenters and even the well established ones can't be trusted?! Need I offer a hint to openssl again?

Oberon and Ada may offer way less libraries but what you get can be trusted to a large degree. Ok, The Pascal GUI thingies are of lesser quality but then that's just GUI thingies anyway. And you know what? I use Freepascal/Lazarus for GUI thingy stuff anyway because I trust that way more than, say, gtkAda; I trust the Ada part but I definitely don't trust the gtk part (and gnome is to be avoided like rattlesnakes on crack).

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


Ad "Habit and high security language":

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

Pretty much all security related problems we experience don't arise out of doors being to weak but out of carton or thin wooden walls, or in computer lingo, out of crappy code.

Even evil attackers do *not* successfully attack systems because these systems have been built properly but, alas, there were 10 minor errors in 5 mio lines code. The entry points that are attacked are plenty and they are created plentiful by crappy code.

Let me offer OpenBSD as an example. OpenBSD is (at least mainly) coded in C. And most of it is rather old code. And it's a Unix. Yet it's - rightfully - considered secure (well, for a standard OS and compared to other standard OSs).

How come? 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.

I could vomitt seeing that OpenBSD does the shitwork while the lisucks foundation is celebrated for politicising and monetizing the openssl disaster.

Boeing and Airbus do, but we generally do not need anal panic perfection. Our problem isn't 1 error per 1 mloc. Our problem is x error per 1 kloc. Our problem is x * n errors in our code, the libraries, the servers, the OSs.
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.

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

Bluntly put my point is: Currently we use trouble generators to produce software and we use quite good quality tools/languages for high reliability/safety/security systems.
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?!


Ad "Ada and elegance":

Sorry, no. There is *no* reason for Ada to invent yet another bunch of terms for well established ones. Similarly there was no bloody reason for Wirth to carry over the ugly and cumbersome (* ... *) comment notation up to Oberon. Neither was there reason for Ada, even later versions, to stubbornly stick to their single line comments only attitude. "--+" almost begs for indicating multiline comments (or commenting out code sections).

Ad "Dewar video":

Oh, that wasn't directed at you but rather as a general rather short, very convenient and casual yet valuable and insightful primer/reminder.


Ad "my own language (version) / tool chain / similar":

I strongly advise against that. It requires way more expertise, craftsmanship, some magic, and major amounts of time and resources to do that *properly*. And there is no need. 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.

Or, if you aren't easily frightened *g* you could design and implement a good mixture of Oberon (OS) and Unix in e.g. Ada.

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. That's on what your Oberon, Ada, Ocaml software runs on. No matter how well designed and implemented your, say, online shop server is; it's doomed to be an open gaping security vulnerability because of that iceberg.


""


""
""

my name is not importantApril 25, 2014 2:16 PM

@Thierry:

"Sadly this report only mentions languages for Web sites and not for general purpose development. OpenSSL + C == Heartbleed..."

No. OpenSSL + lazy coders -> Heartbleed. Would you say OpenBSD, mostly written in C, is unsecure?

Nick PApril 25, 2014 3:05 PM

@ my name is not important

"Would you say OpenBSD, mostly written in C, is unsecure?"

Yes I would. They're certainly not secure. Although, they are better than any other group at preventing and fixing software defects in a C-based, monolithic OS.

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

David ThornleyApril 25, 2014 5:43 PM

To defend C and C++ here:

If the Wikipedia article is accurate (and it agrees with other things I have read), it worked like this:

1. The heartbeat request is received with short text and big character count.
2. OpenSSL then gets enough memory for the character count, not bothering to zero out the extra memory. It copied the text into that space.
3. OpenSSL then wrote out the memory with the character count, including the text and who knows what else.

This is not a buffer overflow (although such things are annoyingly hard to prevent in C). This is an uninitialized memory exploit.

Does anybody else feel nervous when, in a security application, anything gets hold of uninitialized memory? You never know where it's been. If the allocated memory had been zeroed out, all a heartbleed request could get is a whole bunch of zeros, less than useful when hacking a system.

In other words, all the OpenSSL people had to do to avoid this was to use the function calloc() instead of the function malloc(), since calloc() zeros memory. (There's other ways to do it, such as memset(), but calloc() is easy, and you can easily search the program for "malloc" and correct every occurrence). (Assuming, of course, that they bothered to put calloc() into the nonstandard memory manager they wrote themselves and relied on.) In C, for all its faults, there was a way to prevent heartbleed was a style rule that could be enforced with a text editor. Given that the OpenSSL people botched that, I wouldn't trust them not to screw up Ada.

As far as C++ goes, I distrust anybody who uses "C/C++", since they usually are thinking of them as similar languages. C++ started as C with Simula 67 classes bolted on, but it's evolved far beyond that. As an example, I'm going to show how to avoid buffer overruns with a C++ style guide. (I'm ignoring multithreading here, as it is possible to create an overflow with a race condition with the simplified instructions I'm giving.)

Do not use arrays or null-terminated strings. Just don't. Use only C++ containers and strings from the standard libraries (you can supplement the containers, just don't use anything that isn't bounds-checked). As the second part of this, do not use "[]" for subscripting. That may or may not be bounds-checked. Use ".at()" for subscripting; that is guaranteed to throw an exception if it's out of bounds. Finally, never do pointer arithmetic. There: no buffer overflows, using a purely syntactic style guide. (Some APIs, particularly those involving C, do require C-style strings and arrays. Pass data with the .data() or .c_str() calls, and when you receive such data wrap it up in the appropriate container immediately.)

Clive RobinsonApril 25, 2014 7:03 PM

What surprises me is people talking about "Secure Languages" as though they exist... they don't, plain and simple.

If you look at the computing stack, you will see the name of the game from the lowest levels upwards is abstraction. However there is a price to pay in that at each level of abstraction you become progressivly more constrained and thus successivly less flexible in what you can conveniantly do.

We tend to talk of assembler being the lowest level language, it's not by a long way. Assembler is defined by the CPU microcode, that in turn is defined by the available RTL, which in turn is based on logic macros etc etc.

And if you know how, on many modern CPUs you can change the microcode as it's nolonger "hard-coded" in the way it used to be. Which if you know how to do it makes an interesting attack vector which would be difficult if not impossible to detect...

The point to remember though is as you abstract you limit your options, thus the closer you get to any definition of "secure" the less freedom you have. However being heavily constrained does not mean that the programer can not program insecurely, it at best only makes it harder, and as we know humans are fairly good at breaking the shackles that others apply to them.

As some one else has observed the car manufactures went through various stages. However a question has arisen from this, which is,

    Do we drive more recklessly as cars become safer to drive?

And the answer to this appears to be "yes", which if software goes the same way sugests the gains in security will not be that great if we do use more secure languages...

DBApril 25, 2014 10:41 PM

@ David Thornley

"Does anybody else feel nervous when, in a security application, anything gets hold of uninitialized memory?"

Yes... I also feel even more nervous when, in a security application, anything frees memory without zeroing it out. And if it was a private key, maybe it should be written with random data several times first too... although ideally maybe that should be abstracted as a "secure erase" option that lower levels take care of, in case the low level medium needs things done differently than plain overwriting...

yesmeApril 25, 2014 10:45 PM

For the people talking about the UNIX legacy, here is an interesting presentation about that subject. Especially look at page 16 and 22/23.

@Clive Robinson

Plan-9 showed that having tools with less options are actually better than having tools with lots of options. Two examples of this: The GNU Autotools vs BSD Make and "cat -v".

Freedom comes with a price and in the case of computing that price is ambiguity.

WaelApril 26, 2014 2:10 AM

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 mentioned "E" before, so rather than talk about it again, how about looking at it from a different perspective and define the characteristics of a "Secure" programming language instead. We can follow by prototyping it on something like LLVM, then when it looks good, call it "S"? I still think it'll have some issues. The programming language itself will have to be accompanied by mandatory static analysis engine and a dynamic runtime checker (a security specific one), I would imagine... I ignored the effects of HW, The OS, the protocols, etc... just to keep focus on the language. Better light a match than curse darkness, eh? Oh, I almost forgot! It's got to be a general purpose language, too!

Then there is the other approach. Pick the language of your choice and remove all the "bad" things from it, probably call it "C--", how is that for evolution?

CarlosApril 26, 2014 5:14 AM

"Garbage Collected by default (euh... sorry C++ and C)
Productive (euh... sorry C++)"

Actually, and this may have been said already (I didn't read all the comments yet) but C++ does those two very well. Better than C, for productivity, I'd say.

But don't take my word for it...
http://channel9.msdn.com/Events/Build/2014/2-661

And as for what Mr. Stroustrup wanted and wants for C++, instead of some interview from somewhere on the interweb, lets give a hand to the man himself:
http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup

Oddly enough, both videos were made by evil proprietary Microsoft...

yesmeApril 26, 2014 6:16 AM

@Carlos

Come on, you cherry picked these two things?

- Garbage Collected: I meant mandatory. That's the only way to do it right and avoid bugs.

- About productivity: Compile and compile and compile...


Just look at the big picture. C++ sucks. Big time.

Nick PApril 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. :P

" 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. :)

WaelApril 26, 2014 11:41 PM

@Nick P,

The point is there is no single language that's fit for everything. If you are suggesting that the generator you develop generates secure "C" code, then maybe you found a way around the problem ;)
Was not aware "C--" was taken, oh link master...

Mr. PragmaApril 27, 2014 5:26 AM

Nick P

""Would you say OpenBSD, mostly written in C, is unsecure?"

Yes I would. They're certainly not secure. Although, they are better than any other group at preventing and fixing software defects in a C-based, monolithic OS."

Right. There is a great project that is anal about safety & security, there's great coders, there's the right attitude (! - often underestimated an importance) ... and yet there's bug and, although rarely, even a vulnerability. And that's guys who *do* recognize at least a part of C being problematic and find fixes.

Simple thing: *Evidently* even great designers and coders, even with the best attitude, *can not produce reliable software in C*!

-----

You are right about a lot of things and quite obviously you have done your research and did it well. I think the (not too big) differences between your and my point of view mainly stems from our goals. You are looking for perfection (well understood, a worthy goal) while I'm looking how to efficiently and quickly create less problems and vulnerabilities.

In other words, you might be (roughly) summarized as "I want to be able to create a really highly secure system" while I might be summarized as "98% of the current systems can not be made even reasonably well and even a perfectly build server (or program) will rather soon be cracked due to the iceberg below - that must change!"

It seems only natural to me that we have a lot in common. After all we look at the same problems and we look roughly in the same direction searching better paradigms and tools.

I'm shocked by OpenBSD. I mean, you can hardly find better guys, better capability, more experience, better attitude, more of good intention and readiness to go the extra mile - and yet OpenBSD in the end can't deliver better than the crappy, vulnerable next door toy.

For me that's a shocking and frightening proof how right my iceberg asessment is.
(And don't get me wrong. This is *by no means* in any way against OpenBSD. Those guys are to be praised and they just proved their high quality again!)

In a way the language question must be: Is it reasonably possible to produce high quality code with the kind of developers and teams that are available?
With Modula, Ocaml, Ada it is. With C/C++/java it's not. There can not even be a discussion about that after the openssl eruption.

And btw. part of the problem is that people are *abusing* C. Because, again, C was designed as a meta-assembler for low-level OS stuff. Yes, the Unix guys *then* used it for the whole system and even more. But then, *at that time* that seemed appropriate. Neither were significantly better alternatives established, nor was security a major concern.

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

While I personally feel again that you are targetting too much for perfection, I roughly agree. But I think that a solution must, at least first, address the billions of IA32 and Arms out there.

Or in other words: I feel that our problem is not so much that some postgraduate specialists at some intelligence service can hack our boxes. The problem is that thousands and thousands of college boys can make it their hobby to - successfully - attack our systems.

And btw. almost everyone is mad at the crackers. I feel we shouldn't forget to be mad at ourselves, too! After all, we sent the crackers invitations by building and using the mega-crap load in the first place. Even worse, not few in our circles still insist on continued use of C, C++, java ...


@David Thornley (April 25, 2014 5:43 PM)

"... all the OpenSSL people had to do to avoid this was to ..."

But they didn't. And that's almost certainly not because they are worse developers than others.

"Do not use arrays or null-terminated strings. Just don't. Use only C++ containers and strings from the standard libraries ..."

Read that paragraph of yours again. It's basically saying: Don't use C++, rather use Modula, Ada, etc. Because that's what it's coming down to in all but name. Basically you say "Use C++ notation and syntax to program in e.g. Modula". And you know what? That's still worse than Modula or Ada because while it avoids some of C/C++ many traps there are still some more.

Let me, just as one point, suggest that you think about "readability". Because, you see, for instance the openssl source files were written once but - at least should and quite probably - have been read many times. Even worse, often they have been read by someone else.


@Clive Robinson (April 25, 2014 7:03 PM)

You are right. But ...

It seems most security related problems aren't introduced by bad microcode or gate design.

While I don't perfectly agree with Nick P and feel that he is too much on the perfection side and, in my view, somewhat ignorant of the billions of bleeding boxes out there, I also feel that he is right insofar as we must at least strive for and work on secure languages.

Maybe it's, at least in part, a wording problem. Maybe one shouldn't say "secure language" but rather "not bloody insecure vulnerability generators".

"The point to remember though is as you abstract you limit your options, thus the closer you get to any definition of "secure" the less freedom you have."

There you're wrong. There are quite some languages out there that do not limit ones more (than C/C++). For example Ada. I'd have a hard time finding something I could do in C++ but not in Ada. And if you told me one I'd comfortably find some examples for things one can do well and reliably in Ada but not in C++.

And that's me who is not a fervent "100% Ada (or whatever) only!" guy. I had my reasons to mention Ada's interface for C favourably.


@Wael

You are right. No language is "the right one" for *everything*. And even within one area, say dynamic web pages, one must differentiate. For many sites some language toy might be good enough, for my bank I would hate to see some php page.

But there are languages for "almost everything" that have a good track record. Granted Ada won't (and shouldn't) replace Verilog (but Verilog might learn and take sth. from Ada). Nor would anyone in his right mind create the website of the local baker in Ada (or C++ for that matter).

But one *can* - and reasonably - do >90% of an OS, basically every server, and pretty every application in a good "general" language.

As usual GUI is an ugly, ugly, area that spoils a lot. Although I have found some limited kind of peace with Freepascal/Lazarus for GUI stuff (although I certainly dislike it but it seems to be the best compromise).

Nick PApril 27, 2014 12:35 PM

@ Wael

"The point is there is no single language that's fit for everything. "

Definitely true. It's why I'm looking into improvements on assembler and C just as I look into better system languages. I think all will be useful or necessary at some point. Esp considering the legacy problem.

"Was not aware "C--" was taken, oh link master..."

Haha I knew my buddy Wael loved him some links. ;) C-- was more stolen than taken. You can take it back if you like. They're just programmers so should be an easy fight. I got your back.

Sidenote. Original reply was on mobile hence hasty. That you mentioned microcode made me want to point out that there are people trying to do for hardware what languages like Ada or Haskell try to do for software. Bluespec Language and tools come to mind as they're used in CHERI clean-slate project & industry. One newcomer out of academia is Caisson, which aims at secure info flow. Have fun with those.

@ Mr Pragma

"Right. There is a great project that is anal about safety & security, there's great coders, there's the right attitude (! - often underestimated an importance) ... and yet there's bug and, although rarely, even a vulnerability. And that's guys who *do* recognize at least a part of C being problematic and find fixes. Simple thing: *Evidently* even great designers and coders, even with the best attitude, *can not produce reliable software in C*!"

Well said. Same thing I think about them. They're quite excellent at making a known bad approach to security almost come out good. Almost. (evil grin)

"You are right about a lot of things and quite obviously you have done your research and did it well. I think the (not too big) differences between your and my point of view mainly stems from our goals. You are looking for perfection (well understood, a worthy goal) while I'm looking how to efficiently and quickly create less problems and vulnerabilities."

You've correctly described the two goals. We're both looking for the same thing, though, in that we share one. A baseline that prevents many problems & enhances development is desirable. (our shared goal) Hopefully, this baseline can also be a foundation for even higher assurance work. (my extra goal) The best comparison I can give you is Ada vs SPARK. SPARK largely is Ada. That means you can start with Ada for your goal, then use SPARK for (part of) mine. The strategy achieves ease of learning, easy integration with main Ada app, and extra assurance just where you need it. Ada also supports assembler & hardware interfaces when needed.

So, as we talk about various levels from assembler to quite HLL's, I'm thinking of how to apply this concept. So, you say assembler, I think typed assembler. You say C, I'm considering things like Cyclone or C0. I'm thinking "How can we improve whatever we're using at a certain level with minimal impact on developers AND integrate it into rest of code body without problems?" Integration is especially important. For instance, there was a vulnerability for years (might still exist) that occurred when Ada programs linked in C code due to interaction between how each internally structures code or data. A secure Ada program using a library in C would easily be compromised, yet you were safer if including assembler. (Imagine that.)

So, while it comes off setting perfection the minimum, I'm actually just looking for a holistic solution that has quality tools for each job that integrate well and allow selective application of high assurance to various components or layers. Let me give you another quick example you might not have ever heard of: Ten15. They achieved my requirement in a radical way by making a special target language [1] (in a VM) that could safely integrate code written in LISP, Ada, and ML. Quite an amazing feat. You could code on low-level component in a primitive language, code a crypto library in SPARK, code the app in Modula, and link them all together with safety enforced at lowest (software) level. The FLEX computer also enforced this in hardware, so that's doable too.

[1] "Another way of looking at this is that Ten15 was an idealized abstraction of high-level languages, whereas other virtual machines have usually been idealized abstractions of assembly-level languages." (Ten15 developer)

So, I'm just looking at each layer and trying to make them work together. Java largely isn't getting torn up because it's a bad language. It's the integration points and mapping between paradigms (eg JVM code calling native libraries) that get hit the most. Our language solutions to safer apps would likely have the same problem manifest in a different way. So, I feel the solution will require at a minimum at least one "programming in the large" safe HLL, a way to write efficient unsafe code with manageable risk (eg better than C), a way to integrate assembler where necessary, and a way to link these together without introducing any extra risk.

Even in this scheme, I'm still with you on giving the average developer a language that isn't a "trouble generator." We've acknowledged Ocaml, Ada, Modula, etc as meeting that requirement in various ways. Higher assurance tech or languages can integrate with any so long as the core of it is type-safe, memory-safe, and has simple calling conventions.

"With Modula, Ocaml, Ada it is. With C/C++/java it's not. There can not even be a discussion about that after the openssl eruption."

You'd think...

"Yes, the Unix guys *then* used it for the whole system and even more. But then, *at that time* that seemed appropriate. Neither were significantly better alternatives established, nor was security a major concern."

Indeed. That's what people loving C and UNIX must realize: they came from a different world that wasn't full of complexity and black hats. Their design decisions were *fundamentally wrong* for the new situation. Even back then, there were alternatives that would've made most black hats retire. Should be clear to smart developers that, even if they maintain legacy stuff, they should be doing new projects in a different way that's geared to current environment.

"hile I personally feel again that you are targetting too much for perfection, I roughly agree."

Not perfection: safety from ground up with no bypasses via abstraction gaps and integration points. I can't understate this problem. I've seen safe languages and VM's bypassed steadily at various layers from unsafe libraries to SMM mode. One of my efforts concerns languages. Another concerns making architecture that closes the risky abstraction gaps & supports safety/security at ISA level. Hence, as we discuss safe languages, I look for a way to integrate them with safe architectures to force the attacker to work in the straight-jacket of type-safety & POLA regardless of what component they target.

Seeing as systems from 60's-80's already did this, I might as well take a stab at it myself as I look at these software issues. I would feel shame if my 21st century design was inferior in safety to computers designed in the days of rotary phones. Ex: Burroughs B5000 came out around 1961, with touch-tone phones hitting market in 1963. Yes, touch tone phones were cutting edge when many of our software problems were solved by proper architecture. Today, we have Siri and 40's-50's security architecture. Read: insecurity architecture. (Sighs)

Of course, like you said, it's a hell of a lot of work to do such a vertically integrated solution. So, I usually just do an abstract version on paper, post the idea on this blog, and hope someone else with more resources will build it. So, whether I build it or not, I still think the ideas are worth posting on a blog claiming 250,000 readers. Regulars here often see products or papers pop up with specific things that were published here. So, I know we have an effect whether they give credit or not. ;)

"But I think that a solution must, at least first, address the billions of IA32 and Arms out there."

You're right. Due to architecture, the solution will necessarily be different than one that's ground up. The best work in this area uses hardware extensions & software tricks to protect memory, control flow, etc. The best software-only solutions are microkernel-type work such as Dresden's TUDOS and language-level work such as SPIN/JX. Thing is, the legacy code on these architectures is an instant bypass of anything you write in a safe language. So, both my goals can't be achieved there. However, our shared goal of using tools that produce fewer defects is achievable here at each layer where people are willing to sacrifice backwards compatibility and/or their favorite language/tool/methodology.

"And btw. almost everyone is mad at the crackers. I feel we shouldn't forget to be mad at ourselves, too! "

In a previous comment here, I squarely blamed the users for demanding garbage. Then we all got what *they* demanded. Developers, both commercial and FOSS, haven't helped much on this. It's why, if not liability or regulation, I'm for some nonprofit or service model that changes the incentives. That's research in progress.

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

Mr. PragmaApril 27, 2014 1:27 PM

Nick P

Allow me to (only seemingly) ignore what you wrote and to introduce yet another angle into the discussion.

Frankly, I think, many such discussions and reflections are misguided by having fallen prey to a major problem of a different kind, lies (of all sorts and in diverse incarnations, PR Bullsh*t being just one example).

One point I hear again and again is "No single language can solve all problems".

Well this is true. And at the same time it's not.
It's not because of the implicit deduction virtually almost linked to it: And therefore we need many languages. Add some "democracy" bla bla and you arrive at "We need many languages and all of them are equal(ly justified)".

That's bullsh*t.

As an example look at C, the meta-assembler. Nothing, f*cking nothing, did prohibit us from learning and coming to the conclusion that the idea of a meta-assembler was brilliant but it's implementation, C, at least seen from today, was is not the pea of wisdom. Nothing kept us away from creating a better meta-assembler, say, based on a stripped down and then extended/specialized somewhat Modula.

In other words: Looking where bugs are, at what their favourite "bio environment", we would have found out that it's (unrestrained and uncontrolled) pointers, uncontrolled arrays, uncontrolled *allocs and frees, etc.
And something else and more important. We would have found out that humans are not good at meticulously keeping in mind and staying in control of thousands or millions of tiny things - but computers are.

Another example, making a large step into a more modern era, say, the 90ies: multithreading. A classical bio-environment for errors and bugs. Funnily Modula, Ada, Oberon saw and understood that and took care of it - C/C++/java went the other way of adding complexity and problems.

Another major problem area that is in some kind of not-completely-truth fog: *Who* is producing software?
Well, for the by far largest part it's employed developers and open source developers.

And both groups have a major problem. The former almost always are under pressure to produce yet more code and features and versions (read: to create shit just stable enough to not crash right away and such being sellable). The latter are of, to word it very diplomatically, mixed quality.

There is very little middle ground, say proven good open source developers or employed developers with a reasonable time budget and responsible product managers.

THAT's the world we need to take care of (not some few high-sec white castles).

And for that world it would, in fact, be *very positive* to have not one but some few quite similar languages.

It would be great and it would greatly contribute to less buggy software if there was a Modula style meta-assembler, a Modula style general language (say, sth. like Oberon or Ada), and a Modula style scripting language, maybe with inferred typing and some sugar coating.
And that whole shebang cross platform.

Granted, a large part of the open source guys would be pissed of by the compiler saying again and again "Njet!" and would give up (which I, frankly, would consider a major advantage), and many product managers would just hate a 10% longer development cycle - but we would have generally was better software (and after a while even product managers would start to understand that reuseability might have a slightly higher start up cost but would pay for itself multiple times over with further releases).

Funnily, Wirth understood and addressed even that point, albeit indirectly, by complaining about universities being way too much influenced by corporation interests.

But frankly, I'm getting tired because in the end this discussion doesn't make sense. It won't change a thing. Just look at the openssl disaster. The outcome: some very few guys, not at linucks but at a BSD, and not at the big BSD but at the small one, take serious steps. And the *big thing* is some linucks foundation PR, politics, big names, big companies, bla bla and lots of money burnt.

I've learned that lesson and have started quite a while ago to address the customers (they exist and thanks to nsa/Snowden our customer base even grows considerably) who really, really, need reliable software, secure servers, etc.
So, seen from that perspective, let them C/C++/java guys go ahead and create crap - and customers for us. ;)

WaelApril 27, 2014 2:41 PM

@Nick P,

Creators admit UNIX and C were a hoax
Good one and almost believable! Reminds me of: “Truth is stranger than Fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't.”
― Mark Twain

Nick PApril 27, 2014 4:52 PM

@ Wael

Nice quote. I'll have to remember that one.

@ Mr Pragma

"Allow me to (only seemingly) ignore what you wrote and to introduce yet another angle into the discussion."

LOL. Many people ignore what I write. Least you have the courtesy to add something to the discussion while you do it. ;)

"Nothing kept us away from creating a better meta-assembler, say, based on a stripped down and then extended/specialized somewhat Modula."

Some, including Wirth, took that approach so I'd say it's provably true.

re humans vs computers at managing many tiny things; multithreading in various languages

Nicely put for both issue and example.

"Well, for the by far largest part it's employed developers and open source developers.And both groups have a major problem. The former almost always are under pressure to produce yet more code and features and versions (read: to create shit just stable enough to not crash right away and such being sellable). The latter are of, to word it very diplomatically, mixed quality."

Yes

"THAT's the world we need to take care of (not some few high-sec white castles)."

I certainly see your point & focus. Traditionally, when tools & efforts are put into one, they spill over into the other. My research showed much [effective] security/safety tech came from people building castles. Just got copied & integrated into mainstream. I'm with you in that I think it's better for majority of R&D investment to go to improving COTS capabilities rather than high assurance. It will have that much of a payoff when the quality/security increases in commercial sector. So, I'd say 95%+ R&D effort on improving COTS capabilities with rest focused on pushing envelope for reliability/security (eg high assurance).

"It would be great and it would greatly contribute to less buggy software if there was a Modula style meta-assembler, a Modula style general language (say, sth. like Oberon or Ada), and a Modula style scripting language, maybe with inferred typing and some sugar coating.
And that whole shebang cross platform."

We're thinking on similar lines. The more mentally and technically they're connected the better across the board. Each a different level of abstraction, safety, productivity, and effeciency. Each consistent & easily integrated. Just imagine the effect that would have on tooling as well. A change to one might easily be ported to the other. Would be comparable to maintaining one to two product lines rather than half to a whole dozen like now.

"Granted, a large part of the open source guys would be pissed of by the compiler saying again and again "Njet!" and would give up (which I, frankly, would consider a major advantage)"

What I call the Theo de Raadt approach to ensuring OSS code quality. (paraphrasing) "If you don't like our approach, there's the door and there's a cliff. Take your pick."

"Funnily, Wirth understood and addressed even that point, albeit indirectly, by complaining about universities being way too much influenced by corporation interests."

Even funnier, he proved it by developing custom computers that ran a good chunk of the university with software coded in safe, modular, performing languages. While university traded that for COTS garbage, it did prove that safer and more reliable systems were doable for a tiny fraction of what COTS market spent developing their own software. Those fools would've probably saved so much money over time if they had partnered with other universities & got grants to just extend systems like Lilith/Oberon into what they needed. Admittedly, I'm just hypothesizing based on Windows, IBM, and RDBMS luxurious licensing fees extended over decades by lock-in. ;)

"But frankly, I'm getting tired because in the end this discussion doesn't make sense...I've learned that lesson and have started quite a while ago to address the customers (they exist and thanks to nsa/Snowden our customer base even grows considerably) who really, really, need reliable software, secure servers, etc.
So, seen from that perspective, let them C/C++/java guys go ahead and create crap - and customers for us. ;)"

Smart idea. It's been my preferred approach as well. Another guy here (RobertT) said the same thing about Snowden leaks effect on his business. I'm in a tough area for IT in general so I haven't noticed the benefits. Yet. I'll add that your choice of market segment gives you the added benefit of avoiding potential tarnishing of your name when forced to write garbage code for unwise clients. There's something inherently enjoyable about doing the majority of work for clients that want good work done and are willing to pay for it. And your references are almost always positive. :)

David ThornleyApril 27, 2014 5:53 PM

@Mr. Pragma:

The OpenSSL folks didn't even take advantage of the minimal safety abilities C provides. Does that suggest, to you, that they would have done anything sensible in any other language? One little style rule, enforceable by a simple search, would have made the bug unexploitable. (Yes, it would have been better to not leave used memory lying around. That takes a little attention, and I'm looking at what can be done as a matter of habit and easily checked mechanically, and would have left Heartbleed a stupid but harmless error.)

This suggests to me that, if the OpenSSL team couldn't be bothered to take advantage of any safety features, they would have managed to screw up in any language powerful enough to write the software in. Your complaint suggests that you want a language with more safety guards to be unbolted and kicked into the corner, and I frankly don't see the point.

I'm very puzzled by the references to C++. I'm referring to the use of bog-standard C++ features that I use on a daily basis. This is not any attempt to use Ada or Modula or other language, or an attempt to do anything besides idiomatic and readable C++ (although the .at() member function is not all that heavily used), but a brief lesson on what C++ offers, and indeed has offered as long as it's been standardized (about 16 years now). The 2011 standard offers more stuff, but I thought I'd stick to basics.

The fact that you seem to think this is something out of the ordinary indicates that you really don't know what you're talking about in regards to C++. If you wanted to look into it, you might be surprised; after all, you did think that perfectly ordinary C++ code looked like something from a language you like a lot better. If you care to bring up other areas where you think C++ may have security weaknesses, perhaps I can find other boringly normal C++ code that fixes those problems.

Mr. PragmaApril 27, 2014 5:59 PM

Nick P

"The more mentally and technically they're connected the better across the board. Each a different level of abstraction, safety, productivity, and effeciency. Each consistent & easily integrated. Just imagine the effect that would have on tooling as well. A change to one might easily be ported to the other. Would be comparable to maintaining one to two product lines rather than half to a whole dozen like now."

Yep. And each one could strike the right balance in power, convenience, etc.
While the meta-assembler would be much about power but not at all targetting general applications and caring little about convenience (which is an added plus because we certainly don't want hobbyist fumbling sat OSs), the scripting would be quite sugared and convenient, even lending itself to "quick hacks"), yet, enabling a pragma ("strict") immediately point out potential problems and what needed to be better specified to survive the standard compiler (which again throws in a free "concept language and tester").

I'm wondering that Modula and Oberon are severely ill and all but left alone (although it seems ETHZ is reviving Oberon - great!) and even Ada with all the players like Boeing pumping gazillions into it is widely ignored (well, compared to php, ruby, [insert worthless toy or "web basic"]).
I'm smelling corporate interests ...

As you happened to mention it, directly or indirectly, more than once:

I'm sorry but afaic that whole L4 based "security" stuff (calling itself "fiasco"; any further questions?) is doubtlessly well intended but those guys very evidently haven't heard the shot. Security by using C++, virtualization and linucks? Uhum ... Frankly, that reminds me of a term Bruce (iirc) phrased, "security theater"; that should be left to tsa rather than to universities.

Oh and btw., once more something nice (coming from Spain), "MarteOS" (Ada for RTOS) is hardly breathing and, so it seems, lacking support. But OK, "linucks inside" sound nicer and MarteOS doesn't offer that ...

As you are doing so much research in that area: Any hints towards a free RTOS (or mini OS) with a reasonable set of drivers, a reasonable set of supported architectures (min. IA32, Arm, and preferably some more) supporting Oberon or Ada?

Mr. PragmaApril 27, 2014 6:08 PM

David Thornley (April 27, 2014 5:53 PM)

You love C++ and think it's a great language? No problem, just go ahead. And don't be bothered by the fact that even highly reputable ITC researchers and very experienced C++ user consider it next to impossible to even know C++ completely ... Sure enough they also just don't know what they're talking about.

And no, I will not engage in a discussion with someone seriously thinking (I'm polite) C++ is a great language and can be used for reliable, safe, secure software.

This blog is about security. So, kindly accept accept that decision of mine. Sure enough there are plenty "C++ is great" blogs and fora.

Thank you and have a nice week.

Clive RobinsonApril 27, 2014 7:13 PM

@ Mr. Pragma,

    There you're wrong. There are quite some languages out there that do not limit ones more (than C/C++). For example Ada. I'd have a hard time finding something I could do in C++ but not in Ada.

There is a lot more to consider than the "programer view" when looking at security. I often mention "Efficience -v- Security" as an area that is a major cause for concern, especialy where side channels are concerned.

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.

Perhaps not so oddly th saying about "Freedom and Security" applies as much to design and development as much to life in society.

Nick PApril 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 PApril 28, 2014 12:39 AM

@ Mr Pragma

"I'm wondering that Modula and Oberon are severely ill and all but left alone (although it seems ETHZ is reviving Oberon - great!) "

The problem there is, sadly, Wirth. He's great at coming up with things. Maintaining things? Quite the opposite. His pattern is to invent a good language/toolset, build a bunch of stuff in it, and then dispose of it. He & his disciples did this for Pascal, Modula, Oberon, Oberon-2, Active Oberon, Component Pascal, and the recent one I can't remember. Each time, the old one just becomes legacy software. Only one that's really thriving that I know of is Free Pascal because it built on Delphi's legacy. Wirth's & Co's inventiveness is the main obstacle to the success of Wirth-based technology. Life's ironies yet again.

"I'm sorry but afaic that whole L4 based "security" stuff (calling itself "fiasco"; any further questions?) is doubtlessly well intended but those guys very evidently haven't heard the shot. Security by using C++, virtualization and linucks? Uhum ... Frankly, that reminds me of a term Bruce (iirc) phrased, "security theater"; that should be left to tsa rather than to universities."

Lol at Fiasco name. Yeah, maybe that wasn't a great choice. Yet, they're using an approach that has worked well in the past for few that used it. The few systems evaluated to high assurance (eg B3/A1, EAL6-7) took a similar approach. Tannenbaum also makes a good case for them. Thing is, they can be combined with safe language tech. Coarse-grained protection is done by microkernel, with fine-grained protection done by functions. For example, Ada runtimes running on a microkernel side-by-side with apps in untrusted OS partition is already commercial practice. Similar things exist in a few open source projects.

The key points of such an architecture are to keep the TCB tiny and simple, while using hardware protection mechanisms where possible. I have a hard time arguing against that.

"As you are doing so much research in that area: Any hints towards a free RTOS (or mini OS) with a reasonable set of drivers, a reasonable set of supported architectures (min. IA32, Arm, and preferably some more) supporting Oberon or Ada?"

For Ada, there was the Army Secure Operating System, Secure Ada Target, FLEX, and BiiN projects. SAT & BiiN were mostly prototypes, others commercial & delivered. All gone. MarteOS was the only recent project I was aware of. For Oberon, the Oberon System seems to meet your requirements. Latest incarnation is A2 Bluebottle OS. (group page) I'd analyze and trim that joker to get what's worth keeping. Then, expand on that one application at a time. (Esp starting with network appliance or console type apps.)

name.withheld.for.obvious.reasonsApril 28, 2014 6:26 AM

@ et al
Just wanted to way in--was on a Tools Task Force back in the '90s for a large systems manufacturer. My task, along with other members, was to hash out the development environment in a meaningful way. Historically (the experience that was common) was to "find" or "locate" anomolies based on waterfall approach that repetitively cycled through system test and patches. It was useful to have a robust change control and configuration management system in place along with the appropriate toolchain.
Large scale development environments use CASE-based and UML modeling tools to drive top level architecture(s) from specification to operation--being able to generate documentation, versioning, and bug tracking within one environment can be a powerful system...but...when it comes to developing platforms that pay specific attention to quality, performance, and integrity that delivers to the customer is a rare beast. I've seen it once--and--I also saw it "subverted" by a espionage from a foreign government. A separate project that included another operating system project (AFS/NFS services on OS/400). During a routine parsing of the development tree I noticed time stamps for access times changing. "Must be a backup running in operations?" Oops, no one in the ops center--but there is a test running on the project host--but what is this network bionomial distribution test running on the "Winter" machine...but why is it stating all the directories of our research system?
Oh oh, there's a remote network connection to the "Plasma" project system--and it terminates well outside the country. Does the project lead know what's up--I check with the two assigned o the project and the response suggests they're clueless.
Back to the problem, having the host servicing the "Plasma" project to provide mirrored port do a full ethernet dump/trap. Okay, the data is being scooped up by a scripted series of events triggered by the host for the "Winter" project. Maybe the source for the "Winter" project will provide a clue--what is this in the PPT code--it is a worm crawling our server, collecting filesystem namespace data, and shipping it offshore. Do I stop tracking this and report it or do I continue to investigate? Okay, I'll check into it...look the worm is using DNS to enumerate the remote collection site--it's some university...but why? This is a "secret" project--my boss is not going to be happy. And, Jimmy, the lead on the "Winter" project is going to feel a bit used...

David ThornleyApril 28, 2014 12:45 PM

@Nick P:

Thank you for the list of references. The ones that actually talk about C++ seem to be from the early or mid 1990s, when C++ lacked a lot of the abilities it has now.

The first one had some good criticisms, but got into a lot of style issues that the author disagreed with, which rather diluted the effect. There were valid criticisms of multiple inheritance in C++, for example, mixed in with complaints such as C++ allowing unnamed function parameters (such as a declaration like "int f(int);"*). It made it difficult to read. Had the author divided substantive criticisms (such as the rather vague specification of C++'s virtual functions) from desires that the language be designed to the author's aesthetics, it would have been much more useful.

The valid criticisms have generally been addressed by features in C++ standards (complaints about the insecure C-style arrays and strings have been addressed with std::vector and std::string, in the 1998 Standard, while the vagueness of C++'s virtual functions was not really addressed until the 2011 standard), and general agreement to Not Do That (such as the multiple inheritance facilities, which are normally used only with strict rules). There are things the language does not enforce, but any reasonable peer review will, and I don't think I want to use security software that lacked peer review.

Similarly, Ada 95 compares very favorably with pre-standard C++, but not so much with current C++.

I'm not saying here that C++ is necessarily a good language for security software (that's beyond my expertise), but rather that this thread has not come up with valid reasons why it isn't.

*Yes, something like "int f(int);" is unhelpful. However, so is "int f(int i);". While there are languages that enforce some sort of name, I know of none that can enforce a meaningful name.

Mr. PragmaApril 28, 2014 2:24 PM

"Ada 95 compares very favorably with pre-standard C++, but not so much with current C++"

That changes, and brutally so, when comparing current C++ to current Ada (2012) or even just Ada 2005.

And that's what one compares, right. Yesteryears to yesteryears and todays to todays.

I do btw not see a problem with C++. When one is young, that is. Hundreds of debugging sessions and hundreds of bugs later, a *professional* developer (as opposed to e.g. a for fun hacker) starts to think.
Some million stolen credit cards number later a pro starts to think.
After Snowden a pro starts to think.
And after openssl even the smarter amateurs start to think.

Nick PApril 28, 2014 5:54 PM

@ David Thornley

"The first one had some good criticisms, but got into a lot of style issues that the author disagreed with, which rather diluted the effect."

It seems to be unavoidable to have one without the other when getting posts criticizing a language. The problem is that reviewers disconnected enough for true neutrality and focus on facts often have so little experience with the languages their views don't apply to real-world use. So, for me, I just recognize there will likely be bias or subjective stuff if the writer is a veteran programmer, then mentally filter it out. Nearly unavoidable.

"There are things the language does not enforce, but any reasonable peer review will, and I don't think I want to use security software that lacked peer review."

This is the problem. There are many such things that aren't a problem in some other languages even without peer review. I learned this moving from an industrial-grade BASIC & 4GL's to C++ over ten years ago. The easy things were harder to do, programs crashed more (esp using 3rd party libraries), compiles for large modules went from a few seconds to minutes, compiles screwed up more in general, debugging took longer, and I had to make huge checklists of what to avoid. So, I hombrewed a BASIC-to-C++ solution for a while and later switched to Delphi which eliminated many of those problems. I felt the language designs of each contributed to the experiences and results.

"Similarly, Ada 95 compares very favorably with pre-standard C++, but not so much with current C++."

I'm aware it's improved over time, esp if one counts Boost. So did Ada with update in 2005 and 2012. Here's a page that breaks down each langauge feature and how safety is enhanced with language design. You could look at these to make a mental comparison between that and how average and good C++ programmers would do such things. The biggest addition in Ada 2012 is design by contract (Dr Dobbs article).

While trying to find that info for you, I also stumbled upon this article which has an Ada bias, but mentions plenty of improvements in both C++11 and Ada2012 while making comparisons:

http://electronicdesign.com/embedded/c11-and-ada-2012-renaissance-native-languages

It looks like they've been learning from each other a bit. In previous research I particularly liked C++11 standardizing rvalues, smart pointers, strongly-typed enums, lambdas, and static-asserts. These features, imho, will contribute the most to robust code with the exception of rvalue as it's just a nice performance boost. Yet, when I look at Ada 2005 and 2012, the better safety is usually on Ada side. Concurrency stands out with new standard being inferior to both current Java standard and Ada's model from the 90's. Seeing how important concurrency is, lacking productive and safe ways of doing it is quite a drawback.

(Irony is many server-side software directly impacted by such issues are written in C++. Might explain the number of concurrency related bugs & vulnerabilities in them over time.)

"I'm not saying here that C++ is necessarily a good language for security software (that's beyond my expertise), but rather that this thread has not come up with valid reasons why it isn't."

I certainly see what you're saying. My stance is it's a bad language for software period, unless it's extending a legacy C++ app. C++ was proven in at least two empirical studies to have higher quality and maintainability than C. That's it. Other studies showed other languages I mentioned were better than C++ in safety, maintainability, and productivity. Many anecdotes also support this from ex-C++ programmers. Modern imperative languages, esp C# & Scala, add even more features supporting effective language use. Old languages in Pascal, Ada, and even BASIC lines continue to be enhanced in those attributes.

So, given a safe, quick to compile, quick to run, efficient, C FFI-supporting language with good tool and platform support it's hard for me to justify using a language (C++) inferior in every way besides potential efficiency & C integration. Whether high-level or low-level development, there's langauges (esp Ada) that are superior across the board with acceptable performance. The only drawbacks that would make me settle on C++ would be talent availability, amount of existing code in C++, and/or useful library code in C++.

Interesting enough, there are still arguments against C++ in those few situations. The safer languages can use C++ library code by compiling C++ with "extern C," then calling resulting code via FFI & wrapping it in type-safe interface. I did that plenty in BASIC. Existing code in C++ can be done that way or use cross-language development techniques (esp message passing) to extend it using safe language. If it must be *changed*, yeah that takes C++ experts with good knowledge of code base & tool support.

Regarding talent, a few companies using odd languages pointed out that avoiding mainstream stuff filters out the kind of people they'd rather not have. As in, exceptional developers can often pick up a new language with minimal training. And although Ada is tough, the Wirth-style languages are simple enough for a programmer to learn key concepts in a day & master in mere months to a year. It's why they have had a strong presence in Comp Sci education over the years. The students get to focus on applying concepts & solving problems rather than fighting with syntax and compiler. If good talent isn't available, then one would be *even better off* using a language that enforces plenty safety as low talent coders certainly won't pull it off in C++.

So, my default has been to oppose C++ in any new projects unless it's proven to be necessary. I've seen few justifications for loss of clarity, safety & maintainability that comes with it. Reading the CVE's in commercial and open source software supports my point. None are *secure*, yet using one of my C++ alternatives can knock out a number of errors with zero effort & reduce others with less effort. Combined with other benefits, the case against C++ seems pretty clear to me.

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

Mathias HollsteinApril 30, 2014 11:35 AM

First let me say that I agree with Thierry, Joe and others who already mentioned that such research should be taken with a grain of salt.

The study itself tells the reader that basically every language can be used I a secure fashion although there is a clear connection between flawed systems and languages used.

As one commenter on German site heise.de already mentioned there are well designed languages and ones that are not so well designed. User »EinmalMitProfisArbeiten« also mentioned that languages like C should not be compared to interpreted ones like PHP and that skilled developers are able to separate well designed languages and tools from ones that do not match this criteria.

WaelMay 2, 2014 3:37 AM

I don't know if it makes sense to talk about the "security of a programming language". C, for example was not designed to be secure. Security "enhancements" were later additions and were not built-in from the start. Same applies to C++. How could one expect a "secure" language to allow the following expressions to compile and function as expected? Funny thing is that there are some uses for such constructs, although not common and considered "hacks"...Such use of expressions tempts programmers to get "cute", and perhaps is another reason for subtle "security issues"...


#include <iostream>
using namespace std;

int main(int argc, const char * argv[])
{
int array[10];
const char * name = "Schneier's Blog";

// Set array elements to 0,1,2,...,9
for(int i=0; i< 10; ++i)
array[i]=i;

// This compiles
for(int z=0; z< 10; ++z)
cout << z[array] << endl;

// This too (same idea...)
cout << 4[name];

return false;
}

basically x[y] = y[x] because arrays are understood as pointers. I used to ask this question in interviews. Not many people got it right. Probably a lysdexic (or is it dyslexic?) would get it right by mistake ;)

yesmeMay 2, 2014 4:29 AM

@Wael

The problem starts with line 1 and 2 (serious).

#include iostream

using namespace std;

C++ has no modularity and no mandatory namespacing. So you can put any macro in header files that changes the entire program. Sometimes programs even demand a specific order of included header files.

With the Wirth languages (and Go) this is simply impossible.

WaelMay 2, 2014 6:12 AM

@ yesme,
Macros are another problem. In C++, macros are hardly needed! but I doubt you'll see commercial or open source C++ code without macros...

AnuraMay 7, 2014 7:08 PM

@Nick P

"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)

Well, I have to say that I just got the most detailed error message I have ever seen, on a somewhat major news site. This time it's in ColdFusion on Railo+Apache Tomcat, and I have the following:

A structue giving the exact SQL query that errored
The name of the database server
The version of the JDBC driver they are using (10.2.0.5.0)
The version of Oracle they are using (Oracle Database 11g Release 11.1.0.0.0 - Production)
The full stack trace (281 levels deep!).
Plus, a bunch of other dumps of data structures that I'm not that interested in.
They also appear to be using something called FusionReactor

IMPULSE May 8, 2014 10:04 AM

EPIC FUCKING FAIL INDEED BURPSUITE GO !!!!! SQL NINJA WILL LOVE THIS DISCOVERY

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.