Re: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for2002

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Tue, 8 Jan 2002, Francois Leclerc wrote:

> Date: Tue, 08 Jan 2002 16:59:10 -0600
> From: Francois Leclerc <leclerc@austin.sns.slb.com>
> To: Kaz Kylheku <kaz@ashi.footprints.net>, libc-alpha@sources.redhat.com,
>      open-source@csl.sri.com, security-audit@ferret.lmh.ox.ac.uk
> Cc: Russ Allbery <rra@stanford.edu>, a.josey@opengroup.org,
>      tiemann@redhat.com
> Subject: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for 2002
> 
> Kaz,
> I started with 1 point in 2002 wish: portability.

If you want portability, avoid nonportable functions. Portability is
not achieved by getting every vendor to provide the functions
that you want. That just isn't going to happen.

This is simply an instance of the principle that you must
adapt to the world, because the world will not adapt to you.

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

in other words, when the two strings overlap. Is this undefined?  If it
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.  The semantics are likely to be more finely
pinned down once some standardization people get their hands on these
functions. Their adoption into glibc can nicely wait until then.

> Reading this article from Embedded Linux Journal December 2001, 
> http://www.linuxdevices.com/articles/AT9220599952.html
> What shocked me was that a 2001 article was still quoting 36 occurences
> of "strcpy" in a subset of glibc affecting 900+ places.
> http://www.linuxdevices.com/eljonline/issue06/5457s1t.html
> So not only is my computer in 2002 still containing this old 
> vulnerability, but my next VCR, watch, embedded car computer, PDA ...

There is no proof that just because strcpy is called within glibc that
there is a vulnerability.  There are correct ways to use strcpy.

Do you have an actual glibc bug to report or what? If you think
there are incorrect strcpy calls in glibc, look for them and submit
a report via glibcbug or to this list directly.

Better yet, send a patch!

Suppose that you find broken calls to strcpy() in glibc, and suppose
that the best way to fix them is a function like strlcpy. 
Even then, that does not create the need to export such a function
publically from glibc; it's a case for an internal utility funtion
to be created, say __strlcpy, which has no public alias.

> will keep on having this vulnerability ... if there is no clear
> way out of this deprecated C standard calls.

Pardon this injection of fact, but the latest ANSI/ISO C standard has
not marked strcpy and strcat as deprecated.

> PA03: Assess Security Risk (129)
> The threat/vulnerability/impact regarding the vulnerabilities in 
> strcpy/strcat is still too high. A remediation is needed.

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

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

There is no evidence that whatever effect was observed in BSD
communities will be reproduced in this community.

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

> PA22: Coordinate with Suppliers (page  291)
> "BP.22.01: Identify needed system components or services that must be
> provided by other/outside organizations"
> I'm requesting the good people caring for GNU/linux libc to provide
> "a" practical, standard & cost-effective mean to enable application 
> developers to get out of the strcpy/strcat risk. 

You already got it.

I wrote highly portable implementations of these functions, and tested
them. It's about twenty lines of code you can easily add to a C program.
If you don't like them, borrow code from OpenBSD.

Having someone else do most of the work: what could be more
cost-effective than that? What more do you want? To inflict your
preferences on everyone else too?

There are other means to get out of the strncpy/strcat risk. Like,
for instance, stop using a Stone Age programming language for complex
applications that need to manipulate dynamic information!

C++, which is still a Stone Age programming language, has std::string.

In case you don't know, std::string is a standard C++ class which makes
it appear almost as if C++ has first class strings. It hides all of the
buffer management, so the C++ programmer can pretend that string objects
are passed around by value. It has overloaded operators for doing
various things like catenated string.

There is a specialized kind of stream called a stringstream which
can perform output to a string, or obtain input from it. These
streams can be used for in-core text formatting and simple parsing.

All standard since 1998 and de-facto before that, all free of stupid
buffer overflows.

Now if you don't like someone pushing C++ at you, then don't push some
functions onto others.

> I will take as a sustaining point that RedHat is considering the OpenBSD
> security effort trustworthy as it is reselling OpenBSD for
> a secure web server. http://www.openbsd.org/products.html#based

So what? That is irrelevant. The trustworthiness of OpenBSD has no
bearing on what functions should be exported by the next release of glibc.

That trustworthiness is not based on some functions alone, but on a
whole lot of effort by people who are willing to get up to the elbows in
actual code and get things done, and who have the central control
that enables them to do it.  They did a heck of a lot more than just
add a few functions to the library. Adding those functions fit into a
greater plan to actually go through code, code written by other people,
and fix that code, using those functions where appropriate.  Because these
people all work on one big distribution, it makes sense for them to add
the functions to their system's library. They don't have to care that
the programs become nonportable by using their custom functions. They
are willing to throw these programs into their CVS and maintain their
own audited streams of them, which don't necessarily have to compile
anywhere else. 

Linux and GNU development isn't like that. The functions can be added to
glibc, but the glibc developers aren't going to go into everyone else's
program and fix those to use these functions. That's just now how things
work; it would be considered rude. The people who are in charge of fixing
these other programs, they can do so without glibc's adoptation of these
functions. In fact, that is useless to them, because the programs must
work with libraries other than glibc, and these functions are highly
nonportable.

So you see, an approach that works in one community and culture, where
that approach produces certain results, doesn't necessarily translate
to equal results in a different community and culture.

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,
then I allow myself to use POSIX functions. If I'm writing an ANSI C
program, I use only ANSI C functions. That means, for instance, that if
I want to make a dynamic copy of a string in an ANSI C program, I won't
use strdup(), but write my own. If I rely on strdup() I no longer have
a well-defined ANSI C program.  Moreover, if I write my own function
called strdup(), the behavior is undefined because I intrude into a
forbidden namespace. So I call it dup_string() or something like that. If
I use functions that are not in any standard, there has to be a darn good
reason, like gaining access to some very special operating system specific
functionality that is not available through any standard interface.