> A buffer overflow existed in libtermcap's tgetent() function,
> which could cause the user to execute arbitrary code if they
> were able to supply their own termcap file.
>
> Under Red Hat Linux 5.2 and 4.2, this could lead to local users
> gaining root privileges, as xterm (as well as other possibly
> setuid programs) are linked against libtermcap. Under Red Hat
> Linux 6.0, xterm is not setuid root.
>
> Thanks go to Kevin Vajk and the Linux Security Audit team for
> noting and providing a fix for this vulnerability.
So, here I am.
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
TERM variable can be passed using telnet ENVIRON option during protocol
negotiation before login procedure... Guess what?;) Almost remote root
(well, all you have to do locally is puting /tmp/x).
_______________________________________________________________________
Michal Zalewski [lca...@ids.pl] [link / marchew] [dione.ids.pl SYSADM]
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [cellular phone: (0) 501 4000 69]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]
> [...] 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...
Oh, haven't said, for clearance... I'm talking about terminfo support and
tgetent() function implemented in libncurses, which is buggy as well,
while ncurses allows '../' tricks.
> And as Chris Evans pointed out on linux-security, libncurses on RedHat
> is built with -DPURE_TERMINFO, which keeps it from using the buggy
> buffer code in libtermcap.
...not quite true - we're able to cause at least several SEGVs in ncurses'
tgetent() function by putting junk into terminfo files. Simply, try some
brute-force algorithms. I don't want to discuss about possible
consequences of this bug, as we haven't checked carefully terminfo format,
nor parser code.
Are you referring to terminfo or termcap? They are designed differently,
refer to different files and use different code.
Regards,
Joey
--
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto
$ ldd /usr/sbin/in.telnetd
libncurses.so.4 => /usr/lib/libncurses.so.4 (0x40019000)
libutil.so.1 => /lib/libutil.so.1 (0x40056000)
libc.so.6 => /lib/libc.so.6 (0x40059000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
ncurses ignores the buffer parameter to tgetent() that is usable for
exploits.
Note that this doesn't mean everything is safe; there are still
exploitable programs linked with libtermcap. But in.telnetd as delivered
with RH6.0 is fine in this respect.
-Tymm
On Sun, 4 Jul 1999, Michal Zalewski wrote:
> On Tue, 17 Aug 1999, Bill Nottingham wrote:
>
> > A buffer overflow existed in libtermcap's tgetent() function,
> > which could cause the user to execute arbitrary code if they
> > were able to supply their own termcap file.
> >
> > Under Red Hat Linux 5.2 and 4.2, this could lead to local users
> > gaining root privileges, as xterm (as well as other possibly
> > setuid programs) are linked against libtermcap. Under Red Hat
> > Linux 6.0, xterm is not setuid root.
> >
> > Thanks go to Kevin Vajk and the Linux Security Audit team for
> > noting and providing a fix for this vulnerability.
>
> So, here I am.
>
> 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
> TERM variable can be passed using telnet ENVIRON option during protocol
> negotiation before login procedure... Guess what?;) Almost remote root
> (well, all you have to do locally is puting /tmp/x).
>
-Tymm
On Sun, 4 Jul 1999, Michal Zalewski wrote:
> On Sun, 4 Jul 1999, Michal Zalewski wrote:
>
> > [...] 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...
>
> Oh, haven't said, for clearance... I'm talking about terminfo support and
> tgetent() function implemented in libncurses, which is buggy as well,
> while ncurses allows '../' tricks.
>
Do you have any more information about this problem? As far as I can remember,
ncurses doesn't do much parsing with a terminfo file, so there's little
harm that can be done here. Or do you have a demonstrable exploit?
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
ok...@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
ok...@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
[Linux opens files with real not effective UID]
> The problem with telnetd is that you can pass a terminal name that indicates
> 'use a local file'. Now the ncurses library then goes 'ok leading slash
> all well and good', Im not suid uid==euid, lets open it as root and read a
> few bytes. You can't do much with it - you can rewind the machines tape
> drive for example however. Also if your termcap parser has bugs you can
> hit those.
This is fixed in the latest (pre-)release of ncurses-5.0. From the release
notes posted to bug-ncurses mailing list (as of last night) from da man
hissef:
990821 pre-release
+ updated configure macros CF_MAKEFLAGS, CF_CHECK_ERRNO
+ minor corrections to beterm terminfo entry.
+ modify lib_setup.c to reject values of $TERM which have a '/' in them.
So, version 5.0 will no longer accept $TERM that has a slash in it at all,
much less a leading one. I haven't looked closely at the source code, but a
similar change to the 4.2 sources, the version most distributions are using
now, should address this at least where tgetent() is concerned.
> It is a very nice example of why saying "lets ignore XYZ variable" is not
> security but a quick fix for emergencies. If you don't fix the code it
> will get you..
Yep...
Kurt
--
Life's too short to dance with ugly women.
from a COL2.2 system
ldd /usr/sbin/in.telnetd
libncurses.so.4 => /lib/libncurses.so.4 (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x4005a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
i think someone should fix the last post on Caldera's homepage regarding
this vulnerability
http://www.calderasystems.com/news/security/CSSA-1999:020.0.txt
.... Olaf? ;)
> > It is a very nice example of why saying "lets ignore XYZ variable" is not
> > security but a quick fix for emergencies. If you don't fix the code it
> > will get you..
>
> Yep...
wise words
Carlo