Article on secure code

ruby-talk
1

Hello,

Article title: "Too Cool For Secure Code"
Link: http://www.securityfocus.com/columnists/150

This article is not about Ruby, but I think it is very relevant to the
Ruby community. 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.

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

Cheers,

···

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

depone: depone (di-POHN) verb tr., intr.
To declare under oath.

2

Hi!

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

3

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:

sure but using n function means a loss in performance .

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.

sure, there are lots of examples of secure code in C (qmail,postfix),
but anyway is always worth considering the right language for the job.

Having an Airplane control system written in perl won’t just make life
more easy :slight_smile:

···

il Mon, 31 Mar 2003 03:06:52 +0900, “Josef ‘Jupp’ Schugt” jupp@gmx.de ha scritto::

4

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:

sure but using n function means a loss in performance .

But very little compared to the use of a scripting language :slight_smile:

Incidentally, snprintf is actually rather painful to use safely. I
originally wrote some code like this:

char buf[256];
int len = 0;
len += snprintf(buf+len, sizeof(buf)-len, ...);
len += snprintf(buf+len, sizeof(buf)-len, ...); /* etc */

You’d think that would work? It doesn’t. In the event of the output being
truncated, snprintf actually returns the number of characters it would
have written to the string, if it had been given unlimited space. Hence
‘len’ still goes off the end of the string, and subsequent snprintf’s will
write ‘\0’ to bits of memory which they shouldn’t :frowning:

sure, there are lots of examples of secure code in C (qmail,postfix),

Generally, such code ends up building a lot of its own scaffolding for
memory management. I’m not familiar with qmail or postfix, but I have looked
at the memory management code in exim. There’s quite a lot of it.

I think the point is, if you want to write safe code in C (which takes input
from an untrusted source, such as over the Internet), then you need to
realise that you must write this scaffolding as well. The standard C library
doesn’t help you much. However, in a decent scripting language, it’s all
taken care of.

but anyway is always worth considering the right language for the job.

Absolutely!

Regards,

Brian.

···

On Mon, Mar 31, 2003 at 06:10:46AM +0900, gabriele renzi wrote:

il Mon, 31 Mar 2003 03:06:52 +0900, “Josef ‘Jupp’ Schugt” > jupp@gmx.de ha scritto::

5

You mean in the end while looping over bytes also increasing a counter
and checking against a bound. OUCH. Yes, that hurts.

-Martin

···

On Mon, Mar 31, 2003 at 06:10:46AM +0900, gabriele renzi wrote:

il Mon, 31 Mar 2003 03:06:52 +0900, “Josef ‘Jupp’ Schugt” > jupp@gmx.de ha scritto::

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:

sure but using n function means a loss in performance .

6

This is in fact the ideal behaviour if you’re using dynamically allocated storage - you do one speculative snprintf, if that fails, realloc the buffer and snprintf again. Very handy.
The problem is, the return value of snprintf tends to vary between platforms, so you can’t really use it for anything useful in portable code.

···

On Mon, 31 Mar 2003 07:06:46 +0900 Brian Candler B.Candler@pobox.com wrote:

On Mon, Mar 31, 2003 at 06:10:46AM +0900, gabriele renzi wrote:
Incidentally, snprintf is actually rather painful to use safely. I
originally wrote some code like this:

char buf[256];
int len = 0;
len += snprintf(buf+len, sizeof(buf)-len, ...);
len += snprintf(buf+len, sizeof(buf)-len, ...); /* etc */

You’d think that would work? It doesn’t. In the event of the output
being truncated, snprintf actually returns the number of characters it
would have written to the string, if it had been given unlimited
space. Hence’len’ still goes off the end of the string, and subsequent
snprintf’s will write ‘\0’ to bits of memory which they shouldn’t :frowning:

–
Stephen Lewis
slewis@paradise.net.nz