[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54DC0021.7090501@gmail.com>
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.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
