Replies

Many of the most pernicious security exploits in modern software arise from buffer overflows, especially those buffers or variables that are automatically allocated on stacks.

The problem in C (et al) is the concept of an “data-bounded” string, ie, the NULL termination of strings. This runs counter to how strings are allocated in most higher-order languages, where there is a string descriptor or array that the compiler knows is “X so big” and attempts to cram too many characters into the string are caught both at compile time and at run time. In C, there’s no actual bound to the size of a string that the compiler really can enforce. If you allocate an array type for the string, you can use a pointer reference to access the string and write off the end of the string without any warning or exception.

This gives you an idea of how widespread the problem is:

http://web.nvd.nist.gov/view/vuln/search?execution=e2s1

Enter “buffer” in the “Keyword search” box and hit “Search All” - and wait a little while, because it is searching a pretty big DB. You’ll see two things:

1. There are buffer overflows all over the product/platform space. MS, Apple, Google... everyone has buffer overflows.

2. The severity level is usually “high” - meaning that the error can usually be exploited to gain access.

When a buffer overflow is coupled with a system like Windows where the typical user is running as an Administrator.... it’s game over. The exploit can then do pretty much anything it wants.

So how did we get here?

In the 80’s, software vendors were looking for a language that would allow rapid development of software that could touch hardware on microprocessor based systems. Enter C, which was really nothing more than a high level assembler on Unix’s initial implementation on PDP-11’s. For those of us who started on PDP-11’s, you can show us a line of C and we can write out what the assembly code will look like as a result of that line - and 99% of the time, I’ll have it nailed down to the instruction and order of instructions. With modern chipsets, I can’t do that, but C started on PDP-11’s and the PDP-11’s addressing modes influenced the design of C quite a bit.

Being that C is little more than a high-level assembler, there is little to no checking of constraints at run time, because there are few constraints encoded in the source. The whole of C/Unix was sort of a “up yours” response to the Multics OS, which was much larger, much more complicated and written in PL/I. Multics was, however, quite secure.

There is no run-time array bounds checking in C and C-derived languages unless you add in the facility yourself. You can add this with some programming in C++, but it is clunky and not a part of the base language. If we’re going to have run-time bounds checking, it has to be mandatory - not a compile-time switch that has to be enabled (or that can be disabled), and it has to be uniform. We can’t have one shop define their C++ bounds-checked strings one way, and another shop do their “smart strings” differently.

Ada provides run-time constraint checking; when you try to overwrite the end of strings, the run time system throws an exception. There is a good exception handling facility in the language for the programmer to handle other exceptions within the software - in C, there’s only setjmp()/longjmp() and in C++, there’s try... both very mediocre (at best) exception handling.

Here’s a great little example of how mediocre:

http://stackoverflow.com/questions/167199/what-c-c-tools-can-check-for-buffer-overflows

A half-dozen different approaches for something the compiler just does in many other languages.

What Ada brings to the table is strong type checking, strong run time checking and strong exception handling. For a C programmer converting to Ada, getting his first program to compile and link is like getting a root canal. Ada wants things specified down to a gnat’s ass, and C programmers are used to playing fast and loose with type conversions/promotions, interfaces, etc, getting their programs to compile quickly and easily.... and then they start discovering their errors at run time.

When you develop with Ada, the compiler barks at you again and again, requiring that the interfaces, data visibility, types, etc are consistent throughout the program. Very tight compile-time checking is the rule of the day. It can take quite a long time to get the source to compile... but then when it finally does, the program often “just works” without the usual experience C programmers are used to, where it starts running and then there’s a run-time blowup that has to be found and debugged.

As I said, I view security exploits as software reliability failures. There was a bug, someone found it and exploited it to their end. In Windows, for example, there are buffer overruns a-plenty, and again, coupled with the number of people running as Admin... it makes for a very easily exploited system. Unix certainly has the same buffer overflow issues, but unless the exploited program is running with suid, or the user is running as root, the escalation of the exploit is limited.

I’ve developed s/w for more than 25 years, in over a dozen languages and on a dozen+ operating systems. I’ve been around this block a few times. Software errors become security problems very quickly now, and on better systems with better programming languages, the types of exploits we commonly see today were rare by today’s standards.