Richard Heathfield wrote:
> Tor Rustad said:

[...]

>> What has assets of national importance, in common with *apples*???
>
> Okay, let's try something oh so very different.

Why not try something computer related?

>> I be very surprised, if UK or US security professionals these days,
>> will hire people with such a complete lack of understanding of basic
>> security principles.
>
> You have not demonstrated such a lack in your correspondents.

Amazing, I was *not* hiring someone to protect *apples*, *crown* or
looking for a clueless in security, unable to identify *common* errors.

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."

> The strncpy function does a simple task reasonably well. Yes, we all know
> it has a lousy name, but apart from that it's a simple function, easy to
> use properly. Yes, it's easy to use improperly too, but then so are lots
> of C functions.

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.

[1] NIST Special Publication 800-27, "Engineering Principles for
Information Technology Security".

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

C-FAQ: http://c-faq.com/

[ I already wrote a long reply to this, but the newsreader crashed on send
(no, I did *not* write the newsreader, and no, I *will* not write a
newsreader). I don't have time to reconstruct the whole reply. This is a
rather polite summary of my previous, very short-tempered reply. ]

Tor Rustad said:

<snip>

> Amazing, I was *not* hiring someone to protect *apples*, *crown* or
> looking for a clueless in security, unable to identify *common* errors.

(a) you were *not* hiring *anyone*. You were taking part in a Usenet
discussion.
(b) if you think I'm clueless, why bother to continue this discussion?
(c) what if I think /you/ are clueless, unable to recognise *common* sense?

> 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. I have
seen this happen in production code far more than I have seen strncpy
misused (or indeed used at all). In fact, I have seen what we might call
"the char * bug" (if only there weren't so many other bugs that could
easily have the same name) so often that it definitely counts as
disturbing regularity.

If you ban strncpy, logically you have to ban char * too, because it's a
far greater risk. To do otherwise is to be guilty of rearranging the
deckchairs on the Titanic.

<snip>

> 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.

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

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>

Tor Rustad said:

> 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?

Look up "if".

> 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;

See? You do understand about "if".

>>> 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.

Try it on this:

/* foo.h */
#ifndef H_FOO_H
#define H_FOO_H 1
void build_foo(char *foo, int bar, char *baz);
#endif

/* foo.c */
#include <string.h>
#include "foo.h"

void build_foo(char *foo, int bar, char *baz)
{
sprintf(foo, "<h%d>%s</h%d>", bar, baz);
}

What warnings do you get? Compilation need not be done all at one time.


>>> 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.

Fine, so you agree that the best solution is to hire good people and make
sure they know what they're doing?

>> 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.

What do you mean by "clever"? Where I come from, it means "smart, bright,
intelligent" and is considered a compliment. If you mean someone who tries
to write difficult code to show off how well he can write difficult code
(instead of writing easy code that anyone could maintain), I wouldn't call
that "clever".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Tor Rustad said:
....
>> The main risk where I work, is rather the "clever" insiders.
>
> What do you mean by "clever"? Where I come from, it means "smart, bright,
> intelligent" and is considered a compliment.

He's not using the word with a different meaning; he's using it
sarcastically, to describe someone who's just clever enough to create
some very complicated problems, without being clever enough to avoid or
escape those problems.

"James Kuyper Jr." <jameskuyper@verizon.net> writes:

> Richard Heathfield wrote:
>> Tor Rustad said:
> ...
>>> The main risk where I work, is rather the "clever" insiders.
>>
>> What do you mean by "clever"? Where I come from, it means "smart,
>> bright, intelligent" and is considered a compliment.
>
> He's not using the word with a different meaning; he's using it
> sarcastically, to describe someone who's just clever enough to create
> some very complicated problems, without being clever enough to avoid
> or escape those problems.

It's a euphemism for "cocky smartass".

Richard Heathfield wrote:
> Tor Rustad said:
>
>> Richard Heathfield wrote:
>>> Tor Rustad said:

[pissing match snipped, even if I really need to blow off more steam
after a hell of a month!]

> Try it on this:
>
> /* foo.h */
> #ifndef H_FOO_H
> #define H_FOO_H 1
> void build_foo(char *foo, int bar, char *baz);
> #endif
>
> /* foo.c */
> #include <string.h>

???

#include <stdio.h>

> #include "foo.h"
>
> void build_foo(char *foo, int bar, char *baz)

???

broken API design, remember gets()?

> {
> sprintf(foo, "<h%d>%s</h%d>", bar, baz);

???

sprintf(foo, "<h%d>%s</h%d>", bar, baz, bar);

> }
>
> What warnings do you get? Compilation need not be done all at one time.

I don't see the point with analyzing the broken code above.

Not all kinds of buffer overruns can be detected by static analysis, but
I have used splint to check private API's for overruns before. The
idea in splint, is to use annontations, the *requires* and *ensures*
clauses, put in pre- and postconditions, respectively.

Constraints on lvalues, can be set via maxSet() and minSet(), while
constraints on rvalues can be set via maxRead() and minRead(). Those
constraints, set bounds of legal memory access.

Example:

char *my_strcpy(char *s1, const char *s2)
/*@requires maxSet(s1) >= maxRead(s2)@*/
/*@ensures maxRead(s1) == maxRead(s2)
/\ result == s1 @*/;


>>>> 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.
>
> Fine, so you agree that the best solution is to hire good people and make
> sure they know what they're doing?

There isn't a single *best solution* in security engineering, just like
in good software engineering:

bad functional specs, if you screw up design, if you screw up version
control, if you screw up testing ...

the resulting software isn't trustworthy.

>>> 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.
>
> What do you mean by "clever"? Where I come from, it means "smart, bright,
> intelligent" and is considered a compliment. If you mean someone who tries
> to write difficult code to show off how well he can write difficult code
> (instead of writing easy code that anyone could maintain), I wouldn't call
> that "clever".

A common mistake among the "clever", is that they beleave they are
better than their own constraints. Not knowing your own limitation, is a
major security risk IMO. I do by far, prefer humble smartness.

There is a second dimension to this, the vast majority of fraud, is done
by insiders, IIRC ca. 60%-70%.

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

Tor Rustad said:

> I don't see the point with analyzing the broken code above.

Neither do I. In an argument about correctness, I should have taken the
time to compile the example code rather than trust my fingers to get it
right on auto-pilot. But, *had I done so*, it would have been a good
example!

> Not all kinds of buffer overruns can be detected by static analysis,

Indeed. This is kind of my point, really. If you could detect all errors
automatically, you wouldn't need bright programmers. But since you can't,
you do.

<snip>

> There isn't a single *best solution* in security engineering,

Agreed. Nevertheless, the best solution is to hire bright people. Bright
people should be able to work out how not to abuse strncpy, right?

> A common mistake among the "clever", is that they beleave they are
> better than their own constraints. Not knowing your own limitation, is a
> major security risk IMO. I do by far, prefer humble smartness.

That's "clever" as in "dumb", right? Just checking.

The risk of not knowing your own limitations and weaknesses is precisely
the reason that clever people use coding conventions/standards/style
guides, and ask for code reviews by their peers. Indeed, it's why we
bother to do testing. I fail to see how this says anything about strncpy,
though.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999