Re: ncurses buffer overflows (fwd)

[Thomas E. Dickey]

On Mon, 2 Oct 2000, [iso-8859-1] Jouko Pynn?nen wrote:

> 
> 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,

I'd like to see the exploit: there are too many perhaps/maybes in this
discussion that repeat things that are already well known.  (See below - I
don't see a problem fixing the mvcur checks which afaik have been that way
for several years - and am a week or so away from announcing a new
release).

> 
>   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. 

there isn't much that you can do with  $TERM not set.

I have seen some recent discussion recommending that $TERMINFO_DIRS be
suppressed in setuid mode.  (Where do you suppose the library would
get terminal information if the environment variables are reset?)

> 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.

There are in fact limit checks in lib_mvcur.c - you are stating that you
have found an error in that.  Now that you have my attention, I think
you're talking about strcpy'ing the output of tparm - that's a bug.

> 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 made recent fixes for tparm() as it is used in tput.  If you have
an exploit it would be interesting to see (but I think I've made it
as good as the interface permits).

> 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.

there's a lot of distinction between forcing a read to an illegal location
and making a buffer overflow: please don't confuse them.

> 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.

actually, I'll test against current code (4.2 is more than two years old)

> 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
> 
> 
> 
> 
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-ncurses
> 

-- 
T.E.Dickey <address@hidden>
http://dickey.his.com
ftp://dickey.his.com