OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Vuln-Dev Archives: Re: Secure coding in C (was Re: Administrivi

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

Subject: Re: Secure coding in C (was Re: Administrivia #4883)
From: Liviu Daia (Liviu.DaiaIMAR.RO)
Date: Sun Jan 16 2000 - 16:07:31 CST

On 16 January 2000, spin0ff <spinMASSIVE.CH> wrote:
> On Sat, 15 Jan 2000, Liviu Daia wrote:
>
> > On 14 January 2000, Marco Walther <marcowJENA.ENG.SUN.COM> wrote:
> > > >>>>> "BT" == Bennett Todd <betRAHUL.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.Daiaimar.ro
Institute of Mathematics     web page: http://www.imar.ro/~daia
of the Romanian Academy      PGP key:  http://www.imar.ro/~daia/daia.asc

This archive was generated by hypermail 2b27 : Sun Jan 16 2000 - 21:06:14 CST