bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ncurses buffer overflows (fwd)


From: Jouko Pynnönen
Subject: ncurses buffer overflows (fwd)
Date: Mon, 2 Oct 2000 17:00:01 +0300 (EEST)

Hello, I found your mail addresses in the ncurses docs. This is a mail
about some buffer overflows in ncurses to some OS vendors. Btw, after
writing this I found a program "cda" that's installed setuid root by
default in SuSE and available for Red Hat too, it's exploitable with this
problem and gives root access to local users. If possible, I'd ask you to
keep this info from public till we've arranged a deadline day. Thanks,


  Jouko Pynnönen
  Online Solutions Ltd
  address@hidden



---------- Forwarded message ----------
Date: Mon, 2 Oct 2000 14:04:31 +0300 (EEST)
From: Jouko Pynnönen <address@hidden>
To: address@hidden, address@hidden, address@hidden
Cc: address@hidden
Subject: ncurses buffer overflows


This is a brief pre-release of this info. I haven't investigated the issue
fully yet, but I sent this just to give you people more time to prepare
fixes if you wish.

The screen handling library ncurses has buffer overflows which makes
programs using certain of its functions vulnerable. Considering there are
some setuid root programs using ncurses, it means a possible root
compromise. A similar flaw could exist on other similar screen handling
libraries.

The library trusts the environment variables TERM and TERMINFO_PATHS. I
haven't found any version that would ignore them when running setuid. 
Using these environment variables a user can feed their own terminfo files
to the library. The terminfo files normally in /usr/share/terminfo/ define
capabilities a terminal has and the control strings to use them, e.g.
cursor movement.

In the file ncurses/tty/lib_mvcur.c there are some routines to move the
cursor. These functions strcpy() the cursor movement strings without
boundary checking. Thus a user can create a terminfo file with a long
(over 512 bytes is enough) cursor movement string and overflow a buffer.

An application might also get the capability strings themselves with
tparm() and might run into problems if they're very long or contain evil
format strings (this is just speculation).

I've tested this on:
   * Linux ncurses-4.2 and 5.0. The problem exists but I haven't found any
     seriously exploitable programs. "Screen" uses ncurses but doesn't
     seem to use the dangerous routines. "Xaos" (a program I found on our
     SuSE test box) is setuid root and I were able to spawn a shell with
     the overflow, however it had dropped privileges. "Man" is another
     potential program that could give egid=man since it uses less. I
     haven't looked through all exploiting possibilities yet.

   * FreeBSD - /usr/bin/systat gives egid=kmem, successfully tested.
   * OpenBSD - /usr/bin/systat segfaults, but I don't have root access
     on any OpenBSD so making an exploit would take a longer time, haven't
     made one yet.

On systems where telnetd allows setting TERMINFO_DIRS or TERMCAP, it might
be possible to get root access. This seems quite unlikely to me because
telnetd mostly doesn't do any advanced screen magic and neither does
login. However I was able to generate a DoS situation on OpenBSD: by
setting the terminfo file to /dev/zero the telnetd process reads it
infinitely, using up all memory and cpu. The telnetd in question uses
"libocurses".

If you want to test for the vulnerability of things, you can use the
program captoinfo to make a uncompiled terminfo file, modify it (change
name and edit the strings, e.g. "cup" is used in cursor movemtent), then
use tic to compile it to a real terminfo file. Place it in ~/.terminfo and
set your TERM to the new value.

As usual, I'd ask everyone to keep this info from going public yet,
because it hasn't been fully inspected and publishing it now would make
more harm than good. We should probably set an exact deadline to some day
next week or something. Feel free to forward this info to appropriate
people, other vendors etc.



  Jouko Pynnönen
  Online Solutions Ltd
  address@hidden






reply via email to

[Prev in Thread] Current Thread [Next in Thread]