[11463] in bugtraq
Re: [RHSA-1999:028-01] Buffer overflow in libtermcap tgetent()
daemon@ATHENA.MIT.EDU (Aaron Campbell)
Sat Aug 21 09:23:45 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.GSO.4.10.9908191331170.27458-100000@borg.cs.dal.ca>
Date: Thu, 19 Aug 1999 13:55:26 -0300
Reply-To: aaron@CS.DAL.CA
From: Aaron Campbell <aaron@CS.DAL.CA>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <lcamtuf.4.05.9907040046040.500-100000@nimue.ids.pl>
On Sun, 4 Jul 1999, Michal Zalewski wrote:
> Well, as this vunerability become well-known, I have nothing to loose,
> enjoy: most of terminfo-based programs will accept TERM variable set to
> eg. '../../../tmp/x'. All we have to do is to provide 'our own termcap
> file', set TERM, then execute vunerable program w/terminfo support. In
> fact, in.telnetd daemon shipped eg. with RH 6.0 /as well as with many
> other recent distributions based on terminfo entries/, is vunerable... And
That's nothing new, I pointed that out on Bugtraq nearly 2 years ago in
November 1997. In fact, that's the same example I used (../../../tmp/x).
On my test system at the time (Slackware), longer pathnames would be
chopped off at the end.
In general, I consider it dangerous for a program running with elevated
privileges to trust a user-supplied terminfo/termcap file. Last year I
found a buffer overflow in ncurses and OpenBSD was changed to not trust
user-supplied term files when the invoked program is setuid/setgid. A
reasonable precaution; too much could go wrong otherwise.
I also discovered a divide-by-zero bug (again, tickled only by a malformed
terminfo file), which isn't as serious, but could be used to crash some
programs, etc. This was also reported and fixed...
.
: Aaron Campbell <aaron@cs.dal.ca> - [ http://www.biodome.org/~fx ]
`-------------------------------------------------------------------
