[6738] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Overflows in minicom

daemon@ATHENA.MIT.EDU (Alan Cox)
Mon May 11 18:22:02 1998

Date: 	Mon, 11 May 1998 00:40:15 +0100
Reply-To: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
X-To:         11108496@LIS.ULUSIADA.PT
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <Pine.3.89.9805092106.A5465-0100000@tejo> from "Tiago F P
              Rodrigues" at May 9, 98 09:48:55 pm

>  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.

Alan

home help back first fref pref prev next nref lref last post