From: Josef 'Jupp' Schugt <jupp@...>
Date: 2003-03-31T03:06:52+09:00
Subject: Re: Article on secure code

Hi!

* Daniel Carrera <dcarrera@math.umd.edu>; 2003-03-28, 16:05 UTC:
> The author argues that many of the current security holes are due
> to a programmer using C or C++ in cases where a high-level language
> would have done just as well. He points out that many of the holes
> are buffer overflows and string vulnerabilities, and that these are
> not much of an issue with high-level languages.

The problem are programs that use limits for the size of data but do
force-limit the data to that size. Many such programs are written in
C and C++ but that rather means bad programmers. Most problems can be
avoided by using 'n' functions in place of non-'n' functions:

sprintf -> snprintf
strcmp  -> strncmp
   :    ->    :

The problem is that seemingly a large number of programmers do not
even now that the 'n' functions do exist. But that is not to be
blamed on the programming language itself.

Another security hole is dynamic memory allocation using malloc & Co.
Some people do not check if the return value is the null pointer by
assuming 'there will always be enough memory'.

The most important commandment of writing secure programs is Murphy's
law of uncertain assumptions.

   "Any assumption that can fail will immediately result in a remote
    root exploit."

> I find it interesting that one of the arguments for Ruby might be
> that it lets you write more secure code.

That is true for many other scripting languages and also for
programming languages that have strict boundary checking. Note that
some C/C++ compilers allow you to choose between speed (no automatic
boundary checking) and security (boundary checking activated).

Josef 'Jupp' Schugt       http://jupp.tux.nu       jupp(AT)gmx(DOT)de
-- 
"Mankind must put an end to war before war puts an end to mankind."
                                                   -- John F. Kennedy