Re: Overflows in minicom

[Andi Kleen <ak@MUC.DE>]

Alan Cox <alan@LXORGUK.UKUU.ORG.UK> writes:

> >  It seems minicom(distributed with slak3.4) have some overflow
> > vulnerabilities, namely in the '-p' switch and when you pick a config
> > file on the arguments. (a strcpy and a sprintf)
> >
> >  you may test it with:
> >   $ minicom -p/dev/ttyp`perl -e =B4print "A" x 2500=B4`
> >     (Some garbage)
> >     Segmentation fault
>
> That appears to be an understatment at least with minicom 1.81. I've just
> been through doing the usual snprintfing etc. It has stuff like
>
>         strcpy(buffer, getenv("TERM"))
>
> in it.
>
> Its also got a few I8N buffer overruns. This is something that seems to be
> creeping into code as people update it. When you go from
>
>         char buf[31];
>         sprintf(buf,"Hello %.30s",x)
>
> to
>
>         char buf[31];
>         sprintf(buf, _("Hello %.10s"), x)
>
> you blow your protection since a user can set the NLSPATH and catalogs and
> translate catalogs so that "Hello %.10s" becomes "%s"  opening up an
> attack point.

I assumed the libc would ignore NLSPATH when the app runs suid (similar
like it does with LD_LIBRARY_PATH etc.). If it doesn't that is a bad bug.

[... clickety click ... ]

At least glibc 2.1 uses __secure_getenv() for NLSPATH. Don't know about 2.0,
separate GNU gettext, or libc5.

-Andi