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:
> http://www.openbsd.org/papers/strlcpy-paper.ps
>
> 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
> practice.

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:
http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
http://www.blackhat.com/presentations/win-usa-02/halvarflake-winsec02.ppt

> > 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 mailing list