The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Possible overrun in xterm

I'm not sure where to go with this, and I've seen that you guys to a
pretty good job of handling security problems.  So I'm dumping it in
your lap :-)

I discovered a bug in xterm while I was trying to improve its memory
usage, and only recently did I realise that it might be exploitable.

Xterm has a "ScrnBuf" (screen buffer) that is an array of pointers to
information about lines on the screen.  There are three functions that
assume that there are no more than MAX_ROWS (128) lines, and allocate
space (on the stack) accordingly.  These routines are SwitchBufPtrs()
in charproc.c, and ScrnInsertLine() and ScrnDeleteLine() in screen.c.
Xterm will crash if you create a long enough window and then start a
program that uses the ti/te sequences to switch to the alternate
screen.  I have tested this with "less" and seen it happen.  I used
the xterm from the Debian xbase package 3.3-3.

(It's actually a bit more complicated, since there are either two or
three pointers per line, and the functions allocate room for four.
The problem shows up at 257 lines in monochrome mode and 171 lines
(128 * 4 / 3) in colour mode.)

While this corrupts xterm's stack, the data involved consists only of
pointers to data allocated by xterm itself.  Unless there's an opening
created when xterm crashes without cleaning up the utmp data or the
ttyp ownership, I can't think of any way to exploit this.  But I'll
leave that determination to the experts :)

If you're satisfied that this is not a security problem, just let me
know and I'll make a normal bug report.

Feel free to forward this wherever you think is appropriate.

-- 
Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .