Buffer Overflow Attacks and Their Countermeasures (Linux Journal) [LWN.net]

Here's a security conscious Linux Journal article examining buffer overflows. "Buffer overflow problems always have been associated with security vulnerabilities. In the past, lots of security breaches have occurred due to buffer overflow. This article attempts to explain what buffer overflow is, how it can be exploited and what countermeasures can be taken to avoid it."

Buffer Overflow Attacks and Their Countermeasures (Linux Journal)

Posted Mar 11, 2003 0:12 UTC (Tue) by cjcoats (guest, #9833) [Link] (2 responses)

As noted by another responder, the article misses a lot. On the low-tech front, the solution can be as simple as

Program it in Fortran!

Not only is current-standard Fortran a nice and structured language to program in (with very mature compilers, structs, dynamic memory allocation, argument checking), it also has a safe implementation of character strings:

Think of a string as a struct with aq length-field and a pointer-to-contents field.
String assignment has the following semantics:

If the source is shorter than the target, pad the trailing end of the target with blanks; and
If the target is shorter than the source, just copy the leftmost portion of the source that fits, and truncate the rest.

It's string-handling, made safe by design!

fwiw.

Well, if you're gonna say THAT...

Posted Mar 11, 2003 7:05 UTC (Tue) by flewellyn (subscriber, #5047) [Link]

why not just say...?

Program in Common Lisp!

Not only does CL do safe string and buffer allocation (dynamic by default), but it also has built in lists, true multi-dimensional arrays, hash tables, structures, lexical closures, a class system that kicks the pants off of Java's, truly useful macros that operate on parse trees, the ability to treat code as data and vice versa, good garbage collection, clean syntax (what there is of it), excellent compilers available freely as well as commercially (open source ones, too), a portable standard, optimization settings that can be specified in the source input (and aren't just compiler-specific) and varied by function, and a whole lot more! NOW how much would you pay?!

All of this in an executable and core image (for CMUCL) that takes up less than half the space of what GCC requires just for headers. Nor does it need any linker or preprocessor. And it can be faster than C too, if properly optimized.

As for string assignment, the semantics are like this.

Binding a string to a global variable, where the string is read up to a newline from a file stream named "bar":

(defvar *foo* (read-line bar))

Binding a string to a local variable, read from standard input as a Lisp object (i.e., in quotes):

(let ((foo (read)))
;;blah blah stuff with string in here)

See? No worry about truncating, or measuring the size beforehand. And it's garbage collected when you don't need the object anymore. (Or if you want to make it stack-allocated, declare it dynamic-extent and make sure it isn't returned from the body of the LET.)

Buffer Overflow Attacks and Their Countermeasures (Linux Journal)

Posted Mar 11, 2003 15:35 UTC (Tue) by NAR (subscriber, #1313) [Link]

Not only is current-standard Fortran a nice and structured language to program in (with very mature compilers, structs, dynamic memory allocation, argument checking), it also has a safe implementation of character strings:

But if I remember well, there is no check for array indexing in Fortran: and that's what really bites in C...

Bye,NAR