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

[Francois Leclerc <leclerc at austin dot sns dot slb dot com>]

Kaz,
I started with 1 point in 2002 wish: portability.

My interest in the original wish is to pick a simple practical 
information security step which can advance the state of information
security.

Information Security involves a set of engineering processes
http://www.sse-cmm.org/Papers/SSECMMv2Final.pdf 

PA05: Assess Vulnerability (page 145)
I'm using ITS4, RATS (GPL license) ... to highlight the vulnerabilities.
The open-source@csl.sri.com, sectools@securityfocus.com mailing lists 
are good means to learn on tools.

PA04: Assess Threat (page 137)
Although I have not seen the tool, I heard there is some underground
tool
to detect buffer overflow in binary and automate the generation of 
attack scripts. I wish I could find reference of it & quote it.
These kind of threats did not exist 2 years ago, threats do increase 
over time.

PA02: Assess Impact (page 121)
What all GNU/Linux most GNU applications on other OSes have in common ?
glibc 

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 ...
will keep on having this vulnerability ... if there is no clear
way out of this deprecated C standard calls.

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 still too many patches issued after the disclosure
of the attack script of the week in bugtraq leading to a highly costly
patching cycle.
The unitary cost of the remediation is to be looked closely, as only 1
vulnerability usually leads to the full control of the host.

PA07: Coordinate Security (page 159)
"All members of the project team are aware of and involved with 
security engineering activities to the extent necessary to perform 
their function"
IMHO, I'm just attempting to bring awareness in the glibc community
on the effect their decision can make.

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. 

"BP.22.02 Identify suppliers that have shown expertise in the identified
areas."
In my initial request, I provided references to Spaf's book and the
USENIX
paper from OpenBSD.
http://sources.redhat.com/ml/libc-alpha/2002-01/msg00001.html
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 far, the following people has expressed some support in the strl*
request in glibc:

Christoph Hellwig 	Caldera 
David Wheeler          	Author of flawfinder and 
			"Secure Programming for Linux and Unix HOWTO"

Kaz Kylheku wrote:
> 
> On Mon, 7 Jan 2002, Russ Allbery wrote:
> 
> > Date: Mon, 07 Jan 2002 18:36:32 -0800
> > From: Russ Allbery <rra@stanford.edu>
> > To: libc-alpha@sources.redhat.com, open-source@csl.sri.com
> > Subject: [libc-alpha] Re: [open-source] Re: Wish for 2002
> >
> > Thomas Bushnell, BSG <tb@becket.net> writes:
> > > Russ Allbery <rra@stanford.edu> writes:
> >
> > >> strlcpy is useful in situations where you want to just patch the
> > >> problem and don't want to deep analysis of the code to figure out why a
> > >> buffer is being used.  This is an appropriate approach for a porter to
> > >> take.  It's not clear to me that this is an appropriate approach for a
> > >> maintainer to take.
> >
> > > Sure, but libc should be useful for porters too.
> >
> > Yes, on that I generally agree, and I could see some utility in having
> > those functions available to people porting software to Linux, similarly
> > to how having them available in the BSD libc helps people porting software
> > to BSD.
> 
> They are available in BSD because that's where they originated. The
> maintainers of some BSD distribution can take some program which they
> intend to add to the distribution, go through it and fix buffer
> overflow problems using these functions, without necessarily
> understanding the program, or following up on any deeper implications
> of the use of fixed length buffers for strings. That program is then a BSD
> program, its portability is irrelevant since it has been swallowed up
> into the CVS of that distribution. This is not how GNU programs are
> developed at all; GNU programs are still developed with portability
> in mind. Not just portabiilty to standard interfaces, but to
> implementations and old installations.
> 
> Sure it's useful to porters to have as many foreign functions available
> in a library. By that logic, glibc should have all of Win32 in it.
> Writing a five line implementation of strlcpy to make a program work is
> nothing compared to, say, the work required to hack up an emulation of
> the various Reg*() functions to access the registry.  Or should there
> be a threading library compatible with Solaris threads so that people
> don't have to fix their code to use POSIX?

I wish you did not distort my request.
I have not requested a Win32 API.
I have not requested a Reg*() function.
I have not requested a backward compatibility to Solaris.

I'm asking for the help of the glibc maintainers to:
1-Acknowledge that strcat/strcpy vulnerability is not a "glibc" 
vulnerability but a vulnerability in the C standard, which is
implemented
in glibc for the benefit of the GNU/Linux Community.

2-Acknowledge that the reduction of exposure associated with this 
vulnerability is a valid business goal for Linux vendors as it reduces
security emergency patching and provides lower administration cost .

3-Acknowledge that the remediation of this risk has got a cost for
a linux distribution vendor, as it involves all the programs in 
the distribution.

4-Acknowledge that there is a window of oportunity to worry:
The more we wait to implement a *NIX standard remediation, the more
likely Linux users & vendors will suffer damages from this risk. 

5-Acknowledge that the right way to fix 1 library security problem is
to fix it in the library where it appears, not in 500 applications 
indepedently and have 500 strlcat & strlcpy on the same machine.

6-Acknowledge that to be heard by the software community, 
the migration message out of strcat/strcpy has to simple and easy to
learn.

7-Acknowledge that the remediation has to be proposed as standard

> 
> Are the porters whore are moving code from Sun or BSD to Linux really
> in desperate need for help from glibc?

I wish proper respect be used by proper names.

The strcat & strcpy vulnerabilities are in C standard & glibc 
implementation. One of the security risks is replication of code 
which is corrected once but not on the copy. 
My request is to fix the vulnerability in glibc to avoid this residual
risk.

> 
> The people who are primarily responsible for portability are the ones
> who write the application code in the first place; you can't expect
> others, such as the glibc developers, to pick up the slack for lazy
> slobs who write code that is unnecessarily nonportable, or that even
> has no layering to anticipate the need to port.
> 
> By the way, I'm not opposed to the strl*() functions being added;
> I only don't buy the arguments in favor of doing it which have been
> presented so far. There have basically been two arguments:
> 
> 1. Vendors W, X and Y have these functions, so Z should be pressured into
> having them too. Geez, isn't that why we have working groups of people
> to develop these things called standards? The people pushing these
> functions should commit themselves to something solid, like
> participating in a standardization group, rather than pestering the
> mailing lists where nothing will get accomplished.
> 

You got it right, I'm calling for a standardization process. 
Let's talk about it.

I read the refutal from the glibc maintainers that strl* need
to appear first in a standard and contacted few people who posted news 
from standards in ;login: (The USENIX newsletter), and cc the USENIX 
president.

I admit I'm not well experienced in ANSI/ OpenGroup/ ISO/ standards
where
the vote is behind closed doors.I have some experience with the IETF 
and USENIX as I followed them more closely for the last 6 years. I will 
take few examples: SSH, UNIX & IAB move out of cleartext password.

-SSH is a solution developped by a Finnish university to address 
cleartext password and r* BSD vulnerabilities. They wrote a paper 
and provided their code opensource initially.
http://www.usenix.org/publications/library/proceedings/sec96/full_papers/ylonen/ylonen.html

Tatu Ylonen thought it would take 9 months at the BOF in IETF 
http://www.ietf.org/proceedings/97apr/97apr-final/xrtft107.htm

5 years afterward, the secure de-facto standard for remote login is
SecSH v2, which is not yet a published IETF standard. For validation,
check for security counscious opensource OS distributions which do not
include OpenSSH .
http://www.ietf.org/html.charters/secsh-charter.html

-UNIX code predates the C standard, I still need to see a POSIX/ ANSI C
standard not validated by an existing working code.
The IETF requires 2 interoperables implementations to pursue from
a proposed standard to a draft standard, along with some experience.
http://www.ietf.org/rfc/rfc2026.txt chapter 4.1.2
The IETF requires a BOF (Bird of Feather meeting & agreement to start 
a working group).

-IAB
The IAB made a key decision in February 1997: No more cleartext 
reusable password in the IETF protocol, the focus is to actively
obsolete
them in the current standards and forbid new proposal.
http://www.iab.org/iab/secrets.html#Security Considerations
Some times it takes courage to say NO to what has been done in the 
last 20 years. I'm thankful for the IAB for their decision.

Now let's come back to your point.
First I'm sorry the "2002 wish" makes you feel negatively "pressured". 
I wish I knew how to present it better to make it positively 
challenging and attractive.
At the latest IAB plenary meeting, an old timer standard writer, said 
some wisdom words like "In a standard process, the important thing is
not
to be right at the beginning, but to be right at the end."

I'm wishing for strlcat/strlcpy standardization like I wished for 
SSH five years ago because:
-It has been reviewed by USENIX peers with more knowledge than I.

-It tries to address real risks
	. Buffer Overflow risk in strcat and strcpy.
	. Residual risks in strncat and strncpy, namely performance drop,
	change of semantic making the migration a bit too difficult.
	. Cost of risk remediation.

-Standards have a life cycle. They are usually longer than products to
address weaknesses in previous versions. It takes leadership from
GNU, USENIX, OpenGroup, Reliable Open Source and Linux Security Audit 
... members to depart from the old cozy libc API to a more robust libc
API.

-It takes more than 5 years to get an open source security tool and
standard 
widely deployed: It is a good thing that the community is open to change
and a curse that it takes so long in Internet years. 
The consequence is if one waits for a de-jure standard to change glibc, 
he gives 5 years disadvantage to GNU. If we understand we want a
de-facto
standard, we can get many libc providers to implement it in 2002,
OpenGroup
and ANSI to properly accept it according to their process in less years.
This is named "closing the window of opportunity".

I'm open to critics, the proposal is on the table as a discussion is
easier with a draft. You are welcome to propose an alternate API 
and argue in its favor. 

> 2. There are some technical claims we can make about the usefulness of
> these functions. If programmers can find these functions in their local
> programming manual pages, they will see the light and start writing
> much better programs that avoid a class of errors. Well, why can't
> these programmers see the light on their own? What does it take to
> figure out that maybe after cutting and pasting some code several times
> that cleans up after strncpy, maybe it's time to write a simple-to-use
> function that properly null terminates, and reports truncation?

What I like in strl* is its simplicity in remediation.
I find this line of code:
strcpy(pname, dir);

I follow the man page to rewrite as 
if (strlcpy(pname, dir, sizeof(pname)) >= sizeof(pname))
                   goto toolong;

> Geez, should glibc have a networking function that contacts consumer
> retail websites and orders clean diapers and baby formula for the
> developer?

No, this does not match the security requirements of my request.
The design of all and everything in a library is not a security design.
The remediation of a vulnerability in the same library where the 
vulnerability occurs, makes sense for a security practitioner.

With Regards,
--FL, CISSP