Listing the most dangerous parts of C

[Juuso Hukkanen]

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[jacob navia]

Juuso Hukkanen a écrit :

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

What is "t3d" first ???

From that wiki page it is completely imposssible to have an idea what
the hell is that.

jacob

[Arthur J. O'Dwyer]

On Wed, 10 May 2006, jacob navia wrote:

Juuso Hukkanen a écrit :

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )
Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

What is "t3d" first ???

From that wiki page it is completely imposssible to have an idea what the
hell is that.

It's vaporware. This guy's been pushing its "natural language, giant
built-in library of functions" model for at least a year or so, now.
(The problems are that the "natural" language isn't, and the "built-in"
functions aren't.)

FWIW, off the top of my head I'd say gets (obviously), strtok (not
thread-safe), atoi (no error-checking possible), and much of scanf
(again with the error-checking).
scanf("%*s") is fine, but scanf("%s") is evil, scanf("%99s") is
unmaintainable, and scanf("%d") chokes in unpredictable ways on input
like "3287482475 ".

my $.02,
-Arthur

[P.J. Plauger]

"Juuso Hukkanen" <ju***********@ tele3d.net> wrote in message
news:bm******** *************** *********@4ax.c om...

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

One very popular wish list is Misra C. (Actuall two, since there's a
revision out too.) It endeavors to tame C by outlawing all sorts of
usages that some people think *might* be misused.

Another is Microsoft's secure/safer/bounded C, a version of which is
now shipping with VC++ V8. It supplies alternatives to many functions
that can be better bounds checked to avoid storage overwrites. This
work is based on Microsoft's massive bug hunt stimulated by all the
viral attacks on Microsoft software largely written in C.

Neither is anywhere near perfect, nor universally accepted. Both are
places to start.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Richard Heathfield]

Juuso Hukkanen said:

I am looking for a wish list of things which should be removed from
the C (C99)
Absolutely. Just remove C99. Nobody will notice anyway.
- due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>
Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!

strtok() isn't threadsafe, as someone already said, so I guess you would
want to drop that (I wouldn't, but you're not me).

That's about it, I think. Everything else is fine, if you're careful. (Mind
you, scanf, strncpy, and strtok are fine if you're careful, too!)
Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

No, it would be more like saying that if you give power tools to
kindergarten kids, you should expect tears before bedtime.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Rod Pemberton]

"Juuso Hukkanen" <ju***********@ tele3d.net> wrote in message
news:bm******** *************** *********@4ax.c om...

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d
Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

2) 8 C functions suffer from format string vulnerabilities
printf() fprintf() sprintf() snprintf() vprintf() vfprintf() vsprintf()
vsnprintf()

Summary of pdf: Because many C implementations use the same stack for
string data and flow control information (like addresses), the above
functions can modify the flow control information on the stack thereby
allowing authorized code to execute.

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
2) make pointers be associated with a variable before use, not with a data
type
3) eliminate malloc, add dynamic allocation and garbage collection
4) change C to pass by reference
5) require separation of string (and other) data and flow control
information
6) give up now, and try Walter Bright's D language...
Rod Pemberton

[jacob navia]

Rod Pemberton a écrit :

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
????
2) make pointers be associated with a variable before use, not with a data
type
lcc-win32: done.
References are pointers associated with an object permanently.
3) eliminate malloc, add dynamic allocation and garbage collection
lcc-win32: done.
The gc is standard in the normal distribution.
4) change C to pass by reference
?????
Why?

5) require separation of string (and other) data and flow control
information
Stack allocation is ok if used correctly. Making all objects heap based
would slow done everything without a lot of gain in security.
6) give up now, and try Walter Bright's D language...

????

With the above improvements, C can be much easier and safer to program.

jacob

[Keith Thompson]

"Rod Pemberton" <do*********@bi tfoad.cmm> writes:
[...]

I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

[snip]

Obviously this document wasn't concerned just with standard C. A
number of those functions are non-standard. (I haven't even heard of
all of them.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Juuso Hukkanen]

On Wed, 10 May 2006 16:25:42 +0000, Richard Heathfield wrote:

Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!
Ok, strncpy gone. I too I was unsure about it after reading the
http://en.wikipedia.org/wiki/Strlcpy
, but I thought to keep the strncpy for the sake of respect of
standard libraries :)
I see strlcpy could be obtained from the kind donation public
domain by Chuck Falconer, but I am not sure if it is a good idea to
have non-standard C functions inserted. Possible strlcpy is soon part
of the standard.
strtok() isn't threadsafe, as someone already said, so I guess you would
want to drop that (I wouldn't, but you're not me).

Well also the strtok(), (and even gets()) problems see to have better
but still a non-standard solutions provided to public domain by Chuck
(hmmm. Do I see a pattern) .

toksplit()
http://groups.google.com/group/comp....2e03ab0f27f874
ggets()
http://cbfalconer.home.att.net/download/ggets.zip

Thanks for the suggestions
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[Juuso Hukkanen]

On Wed, 10 May 2006 12:56:23 -0400, "Rod Pemberton"
<do*********@bi tfoad.cmm> wrote:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

2) 8 C functions suffer from format string vulnerabilities
printf() fprintf() sprintf() snprintf() vprintf() vfprintf() vsprintf()
vsnprintf()
It's probably this document
http://www.ida.liu.se/~johwi/researc...ate_thesis.pdf
Chapter 7.3.3 Functions which are for attracting buffer overflows
Chapter 7.3.5 Format string vulnerabilities

very good reading , and it gives references to another even better
says...

<snip>
Functions to avoid in most cases (or ensure protection) include the
functions, strcpy(3), strcat(3), sprintf(3) (with cousin vsprintf(3)),
and gets(3). These should be replaced with functions
such as strncpy(3), strncat(3), snprintf(3), and fgets(3)
respectively, but see the discussion below. The
function strlen(3) should be avoided unless you can ensure that there
will be a terminating NIL character to
find. The scanf() family (scanf(3), fscanf(3), sscanf(3), vscanf(3),
vsscanf(3), and vfscanf(3)) is often
dangerous to use; do not use it to send data to a string without
controlling the maximum length (the format %s
is a particularly common problem).
....
Unfortunately, snprintf()'s variants have additional problems.
Officially, snprintf() is not a standard C function
in the ISO 1990 (ANSI 1989) standard, though sprintf() is, so not all
systems include snprintf(). Even worse,
some systems' snprintf() do not actually protect against buffer
overflows; they just call sprintf directly.
</snip>
http://www.dwheeler.com/secure-progr...rams-HOWTO.pdf
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
2) make pointers be associated with a variable before use, not with a data
type
3) eliminate malloc, add dynamic allocation and garbage collection Eliminated by including the Boehms garbage collector4) change C to pass by reference Done in a way that inputs go into functions with values and results
are taken out from the functions by pass by references (or its C
equivalent)5) require separation of string (and other) data and flow control
information The "safe strings" have the first 100 bytes header information about
and for each arrays life, the debug mode collects info from each
function entry - exit. All functions return long long negative values
meaning intelligent error codes.
6) give up now, and try Walter Bright's D language...

D is gainning ground,
http://www.tiobe.com/tiobe_index/index.htm

Because it has everything
http://www.digitalmars.com/d/comparison.html

Well I bet their language definition is bigger than two pages and it
can not be learned in 30 minutes :)
www.tele3d.com/t3d/language.pdf

Thank You
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com