Alan Cox <alanat_private> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:53:16 PDT