Date: Wed, 11 Feb 2015 20:21:37 -0500 From: Daniel Micay <danielmicay@...il.com> To: oss-security@...ts.openwall.com Subject: Re: wordexp(3) On 11/02/15 12:40 PM, Tim wrote: >>> It might be of interest to know that we've only got patches in 2 ports >>> as a result of this: celestia and filezilla (we're using globs instead >>> of wordexp for these; I'm not aware of any negative feedback relating >>> to these patches). >> >> There is software out there which automatically uses a shell-based >> implementation if the system does not provide wordexp. With this in >> mind, it makes sense to provide the interface even if you dislike it >> (same thing with strlcpy). > > > I disagree. > > Providing a badly designed interface, even if it is "standard", simply > invites more depedence on it. If people have to exert extra effort to > code around the lack of a dangerous interface, then they are less > likely to rely on dangerous approaches, such as generating shell > syntax from within C. Yes, they could just use system() or popen(), > but these interfaces should be deprecated as well. We have to take a > stand some time. ISO C and POSIX are primarily composed of badly designed interfaces. If it was as simple as iteratively improving the interfaces and dropping compatibility for the old ones, then the C standard library would be a drastically different beast. A large portion could be immediately discarded due to thread unsafety along with dropping the locale and wide character mess and replacing it with sane UTF-8 and Unicode Scalar Value support. C strings should certainly go too, considering that they're both needlessly error prone and slow. The worst part is forcing dynamic allocation and copying in order to view substrings. I don't think there's much that would be kept if it was as simple as providing a better interface, deprecating the old ones and then removing them shortly thereafter. > Most programmers like to think that other programmers should just > "know what they are doing" and use these interfaces with care. The > reality is, there will always be a significant percentage of > developers who don't "know what they are doing". If we want to avoid > vulnerabilities in software, we need to start thinking about how to > provide APIs that discourage (but don't prevent) unsafe practices, so > that those who are naive will find that the path of least resistance > is to write secure code to begin with. The obvious first step is writing new software and new components for old software in languages that are memory safe and aren't filled with poorly designed legacy APIs. It worked out quite well for Android... C is fundamentally based upon placing a huge amount of trust in the programmer, and has lots of historical baggage like this. Since wordexp is so rarely used it's hard to see why it's getting so much attention. We live in a world where you can just grep around for malloc/realloc in most C projects and find dozens of heap overflows... this is a blip on the radar. [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ