Return-Path: <sentto-279987-4259-1010584612-fc=all.net@returns.groups.yahoo.com> Delivered-To: fc@all.net Received: from 204.181.12.215 [204.181.12.215] by localhost with POP3 (fetchmail-5.7.4) for fc@localhost (single-drop); Wed, 09 Jan 2002 05:58:08 -0800 (PST) Received: (qmail 20942 invoked by uid 510); 9 Jan 2002 13:57:12 -0000 Received: from n4.groups.yahoo.com (216.115.96.54) by all.net with SMTP; 9 Jan 2002 13:57:12 -0000 X-eGroups-Return: sentto-279987-4259-1010584612-fc=all.net@returns.groups.yahoo.com Received: from [216.115.97.190] by n4.groups.yahoo.com with NNFMP; 09 Jan 2002 13:56:53 -0000 X-Sender: fc@red.all.net X-Apparently-To: iwar@onelist.com Received: (EGP: mail-8_0_1_3); 9 Jan 2002 13:56:52 -0000 Received: (qmail 59284 invoked from network); 9 Jan 2002 13:56:51 -0000 Received: from unknown (216.115.97.171) by m4.grp.snv.yahoo.com with QMQP; 9 Jan 2002 13:56:51 -0000 Received: from unknown (HELO red.all.net) (12.232.125.69) by mta3.grp.snv.yahoo.com with SMTP; 9 Jan 2002 13:56:51 -0000 Received: (from fc@localhost) by red.all.net (8.11.2/8.11.2) id g09DvTk15431 for iwar@onelist.com; Wed, 9 Jan 2002 05:57:29 -0800 Message-Id: <200201091357.g09DvTk15431@red.all.net> To: iwar@onelist.com (Information Warfare Mailing List) Organization: I'm not allowed to say X-Mailer: don't even ask X-Mailer: ELM [version 2.5 PL3] From: Fred Cohen <fc@all.net> X-Yahoo-Profile: fcallnet Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com Delivered-To: mailing list iwar@yahoogroups.com Precedence: bulk List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com> Date: Wed, 9 Jan 2002 05:57:28 -0800 (PST) Subject: [iwar] [fc:glibc.-.a.common.mode.failure.for.most.Unix/Linux.software] Reply-To: iwar@yahoogroups.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tue, Jan 08, 2002 at 18:42:06, kaz wrote about "Re: ...: 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. ------------------------ Yahoo! Groups Sponsor ---------------------~--> Sponsored by VeriSign - The Value of Trust Do you need to encrypt all your online transactions? Find the perfect solution in this FREE Guide from VeriSign. http://us.click.yahoo.com/vCuuSA/UdiDAA/yigFAA/kgFolB/TM ---------------------------------------------------------------------~-> ------------------ http://all.net/ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.1.2 : 2002-12-31 02:15:02 PST