Bugtraq mailing list archives
Re: Overflows in minicom
From: ak () MUC DE (Andi Kleen)
Date: Tue, 12 May 1998 05:51:00 +0200
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 faultThat 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
Current thread:
- Re: Overflows in minicom Tiago F P Rodrigues (May 11)
- <Possible follow-ups>
- Re: Overflows in minicom Andi Kleen (May 11)
- Re: Overflows in minicom Stefan `Sec` Zehl (May 12)