This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for 2002


(Cc list wasn't cut)

 Tue, Jan 08, 2002 at 18:42:06, kaz wrote about "Re: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for 2002": 

> > PA02: Assess Impact (page 121)
> > What all GNU/Linux most GNU applications on other OSes have in common ?
> > glibc 
> 
> This dependency means that once you add functions to glibc, you have to
> support them indefinitely. The functions in questions have poorly
> defined semantics. For example, I can't find anything in the BSD
> man pages regarding what the behavior should be of
> 
>   strlcat(buffer, buffer, sizeof buffer);

I can't find anything in the glibc man pages what the behavoir should be
of strcpy(buffer,buffer). Does this mean that strcpy() is poorly
documented in glibc and should be removed? No smiles here.

> should be considered undefined, will it change in the future? The
> current specification is written by people who don't know how to
> write standards. They haven't even managed to get the man page to match
> with the implementation.

Please describe the exact inconsistency with exact and full specification
of version in use. For current FreeBSD and OpenBSD, I cannot find such.

> There are no vulnerabilities in strcpy and strcat, but in their incorrect
> use. As an implementor, there is nothing you can do with strcpy and
> strcat other than to implement them correctly.
> You cannot prove that a program has a vulnerability on the basis that
> ``grep -E '\<strcat|strcpy\>'  *.c'' on that program returns a successful
> status. :)

The vulnerability is in ideology. There is no infinite character buffer
in practice, it exists only in pink dreams of Kernighan, Ritchie and Thompson.
Real object of computer internals world is buffer of limited size.
strcpy, strcat writes to non-existing infinite buffer. strlcpy,
strlcat writes to buffer of known size, this size must be explicitly specified.
strcpy, strcat, strncat (especially!) leads to bad style and heavy bugs.
It can be proven with quite enough probability that each program larger
than "Hello, world!", working with text and having strc*() in its code
has buffer overruns, unless irrational money was spent to fix its bugs.
glibc is distinctive example of large program.

Functions like strlcpy() have the big advantage: they require buffer size
directly near buffer pointer, in the same parameter list, and this can
be easy checked, instead of strcpy-based speculations like "add up to 200
characters in subsys1/mod1/f42378964.c, up to 150 characters in
lib34987/cc23987.c, and define size 351 in include/internal25/xxxyyy.h",
which is almost immediately broken by later development. Requirement of
buffer size directly near its pointer helps to write clean and correct code,
allowing of keeping its in another place leads to heavy bugs. This is
nude practice statistics fact, and it is proven in psychology.

> > IMHO, I'm just attempting to bring awareness in the glibc community
> > on the effect their decision can make.
> That is arrogant and naive, because it assumes that the glibc
> community has no awareness of security issues.
>
> Moreover, what effect the decision has is only your *opinion*, not a
> fact. There is no evidence that adding some new functions to glibc will
> magically make a whole bunch of security issues go away.

The sentense "the glibc community has good awareness of security issues"
is also your opinion, not a fact. "glibc community" is too wide term
than to use it without fiddling. Let's avoid such constructions.

> Some proprietary UNIXes have these functions now, yet continue to have
> security problems. 

Yes. strlc*() does not provide a panacaea against all another class
of bugs except simple buffer overrun. It also can make some problems deeper,
e.g. when buffer overflow didn't break program, but with ctrlc*() string
was cut without any warning. And this is good, because helps to detect
other bugs.

> I can tell you right now, that I would not use these functions if they
> were in glibc, even if I wrote code that needed them.  If they fit what I
> happened to be working on, I would write my own implementations. I write
> code to *standards*. If I decide that I'm writing a POSIX application,
[...skip...]

Standard is based on better practice. Standard is not constant-forever.
All your large text on topic "To follow standards is good, to use
non-standard stuff is evil" is non-sensable here due to simple fact that
standard is not originated from clear vacuum, but from real-world realizations
with their features and experience luggage. If one require a function,
he invents it. If one think that a function is good, he includes it
to a library, in spite of all standards (but not conflicting with them),
and marks it as local feature. Each programmer can test, with help of autoconf
or without it, for presence and use own version or optimized version
provided in system library.
You are against strlc*() and this is the real reason why you are against
them in glibc; if you were "pro" them, you would vote to include them. glibc
contains a lot of "non-standard" BSD compatibility stuff, and nobody
died due to its inclusion. To append two little and useful functions,
heaven won't fall to land, but standartizing of strlc*() will got a solid
help, also helping to remove obsolete crap.

> C++, which is still a Stone Age programming language, has std::string.
> Now if you don't like someone pushing C++ at you, then don't push some
> functions onto others.

Yes, and this is the great step comparing to nul-terminated strings.
Does this mean IYO that all C programs working with text should be
immediately converted to C++ programs?

It would be quite better to use normal string technique, instead of
the misunderstanding used in C. But this is topic of another thread,
not the current one where the problem to help in fixing of existing
software is discussed.

Comparatively with a majority of unix software, I would be happy to
see pushing to C++: it would help them to fix hereditary chronic lameness.

* If builders made buildings the way the programmers writes programs
  civilization could be destroyed by a woodpecker.


/netch


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]