Re: Secure coding in C (was Re: Administrivia #4883)

[Liviu.Daia () IMAR RO (Liviu Daia)]

On 16 January 2000, spin0ff <spin () MASSIVE CH> wrote:
> On Sat, 15 Jan 2000, Liviu Daia wrote:
>
> > On 14 January 2000, Marco Walther <marcow () JENA ENG SUN COM> wrote:
> > > > > > > > "BT" == Bennett Todd <bet () RAHUL NET> writes:
> > > BT> For a specific case, is there any security hole directly
> > > BT> implied by this C fragment, assuming attackers could control
> > > BT> the contents of a and b?
> > >
> > > BT>       char *a = something();
> > > BT>       char *b = something_else();
> > > BT>       int len = strlen(a) + strlen(b);
> > > BT>       char *c = malloc(len + 1) || die("malloc");
> > > BT>       (void) strcat(strcpy(c, a), b);
> > >
> > > I don't see any problems here;-)
> > [...]
> >
> >     Oh, come on.  What if a and b are not null-terminated?
>
> both strlen call will return when they encounter a \0, implying that
> after the third line, len will be long enough to hold a, b and the
> garbage following both a and b. c will be large enough to hold all of
> this.
>
> c will probably not contain something useful if a and b weren't
> null-terminated... but could someone point out a scenario where it
> could be possible to exploit this ?

    That's not the point: this particular case is probably harmless, but
in the real world you're likely to need less trivial length calculations
--- and messing up some of them *might be* exploitable.  IIRC, the
snprintf() behaviour in Linux libc5 mentioned in another post (which
was, BTW, a bug, not a feature) is an example of such a problem.

    Regards,

    Liviu Daia

--
Dr. Liviu Daia               e-mail:   Liviu.Daia () imar ro
Institute of Mathematics     web page: http://www.imar.ro/~daia
of the Romanian Academy      PGP key:  http://www.imar.ro/~daia/daia.asc