Richard Heathfield wrote:
> Tor Rustad said:

> (b) if you think I'm clueless, why bother to continue this discussion?

So, you wouldn't have replied then, given the same conditions.

if ( tor_eval(richard) == cluless )
goto no_reply;


> (c) what if I think /you/ are clueless, unable to recognise *common* sense?

This didn't make any sense, you did reply, didn't you?

Either "I think /you/ are clueless" is *false*, or you are posting
nonsense. You cannot have it both ways:

if ( richard_eval(tor) == cluless )
goto post_reply;



>> For an introduction to basic security principles, see e.g. [1]:
>>
>> "Principle 32. Identify and prevent common errors and vulnerabilities
>>
>> Discussion: Many errors reoccur with disturbing regularity - errors such
>> as buffer overflows, race conditions, format string errors, failing to
>> check input for validity, and programs being given excessive privileges.
>> Learning from the past will improve future results."
>
> In my experience, the following bug is far more common than strncpy:
>
> char *t;
>
> strcpy(t, s);
>
> The bug here is in failing to allocate *any storage at all* for t.

Such an error, is detectable by statically checking tools, if compiler
doesn't catch it, lint tools like e.g. splint does.

$ cat -n main.c
1 #include <stdio.h>
2 #include <string.h>
3
4 int main(void)
5 {
6
7 const char *s = "Hello";
8 char *t;
9 char d[5];
10
11 /* BUG 1 - storage not allocated */
12 (void)strcpy(t, s);
13 (void)printf("'%s'\n", t);
14
15 /* BUG 2 - destination buffer not null terminated */
16 strncpy(d, s, sizeof d);
17 (void)printf("'%.*s'\n", (int)sizeof d, d);
18
19 /* BUG 3 - destination buffer truncated */
20 strncpy(d, s, sizeof d - 1);
21 (void)printf("'%.*s'\n", (int)sizeof d, d);
22
23 return 0;
24 }
$ gcc -ansi -pedantic -W -Wall main.c
$ splint main.c
Splint 3.1.1 --- 20 Jun 2006

main.c: (in function main)
main.c:12:15: Unallocated storage t passed as out parameter to strcpy: t
An rvalue is used that may not be initialized to a value on some
execution
path. (Use -usedef to inhibit warning)

Finished checking --- 1 code warning
$

Note that the bugs of class 2 and 3, gives no warning above.


>> The *relevant point*, is that this C function has been misused a lot,
>> and a buffer overflow can result in a total compromise of a computer
>> system. The probability of misuse, isn't low either.
>
> So ban pointers. They cause far more trouble than strncpy.

To be honest, in safety-critical or security-critical software, I can't
ever remember being hit by buffer overflow or unallocated storage, in
production. Before someone is allowed to do the real thing, they need to
master the basics.

However, I have looked at alternatives, for example cyclone:

http://www.cs.umd.edu/~mwh/papers/cyclone-cuj.pdf



> FCOL, Tor. Wake up and smell the real risk - clueless programmers, hired by
> witless buffoons because they have good hair and a good CV.

The main risk where I work, is rather the "clever" insiders.

--
Tor <torust [at] online [dot] no>