strl* (was: Re: Advent4 patch, second try)
Luis Javier Merino
ljmerino at gmail.com
Fri Sep 28 17:15:48 CEST 2007
On 9/28/07, Stefan Sperling <stsp at stsp.name> wrote:
> This shows you haven't read the paper.
I actually have read the paper, but it was so long ago that I don't
remember every detail.
> strl* don't want to solve all possible string problems.
> See the section "What strlcpy() and strlcat() are not" in the paper:
> strl* want to provide an API for strings in fixed-sized buffers
> that, if used, *eliminates* the possibility of buffer overflow attacks.
> (Note: eliminate, not just "make less likely" or something like that.)
My problem with strl* is that they are usually pushed as the ultimate
solution without discussing dynamic strings.
> > For the record, I'm not pushing for bare memcpy, I'm pushing for
> > dynamic strings.
> The only main difference between heap and stack allocations is
> that one puts the buffer on the stack and the other on the heap.
> Buffers on the heap can be larger than buffers on the stack,
> and they can dynamically change their size. So you want heap buffers for
> strings that you want to grow or shrink dynamically, but using stack
> buffers for (relatively) fixed-sized strings is just fine and common
I guess we agree here. Maybe I disagree in that I think that
dynamically growing strings are quite common in practice, and one of
the reasons people start looking for alternatives to the clumsy
traditional str* functions. So people should be told of dynamic
strings, maybe in addition to strl* _for fixed strings_.
> In many situations, like filenames, the OS imposes limits
> on the maximum size of the string anyway, so what's wrong
> with "char path[MAXPATHLEN];" ?
Point conceded as long as people abort/realloc on strl* failure. I'll
raise another :) str*cat is inefficient.
> The fact that heap buffers are a tad harder to exploit than stack
> buffers is irrelevant, because heap overflows are a very well
> understood problem, too.
They are actually easier to exploit, see:
> > If there was any
> > standard for dynamic strings I'd guess noone would oppose strl* meme
> > propagation.
> But what has an API for dynamic strings got to do with an
> API for fixed-sized strings?
I'm talking about strings in general, not about fixed-sized strings.
> I'm not at all against a good standard C API to handle dynamic
> strings. That would be great! The same argument about good APIs
> I made earlier applies.
Then we agree here.
> But at least with strl* the other libc's I've mentioned have the
> equivalent for fixed-sized buffers. Which is far from perfect,
> because the overflow problem remains for badly managed heap buffers,
> but at least it's a step in the right direction.
> I don't understand why some people think this is bad.... :-/
> Solving one problem at a time seems to be a reasonable approach to me.
And we come to my real point. I want people to suffer until they start
lobbying for dynamic strings. Yes, I have a hidden agenda.
More information about the dslinux-devel