[6747] in bugtraq
Re: Overflows in minicom
daemon@ATHENA.MIT.EDU (Andi Kleen)
Tue May 12 01:37:49 1998
Date: Tue, 12 May 1998 05:51:00 +0200
Reply-To: Andi Kleen <ak@MUC.DE>
From: Andi Kleen <ak@MUC.DE>
X-To: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Alan Cox's message of Mon, 11 May 1998 00:40:15 +0100
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
