On Mon, 14 Jan 2002, Prof. Brand wrote:

> <mouringetoh.eviladmin.org> said:
> > On Sat, 12 Jan 2002, Paul Eggert wrote:
> >
> > [..]
> > > No, it is defensive programming that leads to misbehavior, because the
> > > code can end up using a different ticket-granting instance name than
> > > was requested.
> > >
> > > I don't know whether that misbehavior can be exploited. However, it
> > > would be safer if the code reported an error instead of silently
> > > misbehaving when the host name is too long. This would improve the
> > > quality of the defensive programming.
> > >
> > > This problem suggests that you might want to sweep the code and remove
> > > all instances of strlcpy/strlcat. Instances such as the above can be
> > > replaced with strlen + fail-if-too-long + memcpy; that would improve
> > > code safety. Instances such as the previously-mentioned one can be
> > > replaced with memcpy; that would be simple, standard, and just as
> > > safe.
>
> > People keep bring up.. "Oh short terminated strings could be a security
> > risk."
>
> > Can you provide a single proven case where correctly written function
> > calls can be explioted due to 'too short' of input? This seems to be the
> > heart of most of your arguments, but I can not find a single such case.
> > If that case existed would it still be the fault of strl*() or because
> > someone fucked up the routine accepting the input? I would lay blame to
> > the latter case since anyone fool who can read code can expliot the 'too
> > short' case first.
>
> When handling security, you want to prove that it is _impossible_ to create
> a security risk; that noone has ever seen one is far from enough.
>
> If your "chop off the tail and be happy" changes "some.place.com.br" into
> "some.place.com" it _certainly_ could open up a security risk (very hard to
> exploit, but still).
>
Same risk occurs with strncpy() so it no additional scurity risk is
provide.

> > Note: I'm refering to correct usage of strl*() not abuses like:
> >
> > int my_unlink(char *longer_than_MAXPATH) {
> > char path[MAXPATH];
> >
> > strlcpy(path, longer_than_MAXPATH, sizeof path);
> > return unlink(path);
> > }
> >
> > which is an abuse you can see a mile way, and easily detectable
> > by wrapping strlcpy() in a in a: if ( .. > sizeof path) test.
>
> What is the point of strlcpy's check then? Just use strcpy(3).
>
> > Personally, I would rather fail a string truncation safely than sorry.
>
> How is a dumb library function to know when it is safe to truncate and when
> it is risky?

Never said it would.. But it is consistant. the truncated string ALWAYS
has \0 and NEVER overwrites the next veriable on the stack/heap/whatnot.

Can you say the same about other string functions?

If this is the only 'proof' that strlc*() are "security risks" then it is
pretty weak. And I'd stick with "It is not a SUS/POSIX standard" since
that is something we can all agree on.

- Ben

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]