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]

Re: Possible overrun in xterm

Mark Eichin wrote:
> Interesting analysis.  Clearly there's a bug.  While it may be
> difficult to exploit, I would be reluctant to assume it is impossible,
> and from your description it sounds easy enough to fix.  I'll look at
> the code myself, but did you happen to construct a fix while you were
> in there? 

I'm afraid not.  I see several possible strategies:

  - Enforce MAX_ROWS when creating or resizing the vt100 widget.
    This may mean backward incompatibility, but if MAX_ROWS is set to
    256 at the same time, it won't break anything that wasn't already
    broken.
    Finding all the places where the widget can be sized may be tricky.
  - Change those routines to allocate on the heap instead of on the stack,
    so that they can allocate enough space.  This may have significant
    speed impact, since ScrnDeleteLine and ScrnInsertLine are heavily
    used (scrolling).
  - Change those routines so that they do not need temporary storage.
    SwitchBufPtrs just swaps two arrays, this could be done
    element-by-element.  The other two perform internal swaps of some
    kind, this is more tricky to rewrite but it should be possible.
  - Use a global malloced buffer.  It should be easy to grep for all
    allocations for screen->allbuf, and add a realloc() to the same
    size for this global buffer.
  - In each of these routines, check if n > MAX_ROWS before doing any
    copying, and print an error and do a clean exit if so.  This will
    prevent any security problems but is obviously not elegant.

(I spent some time analyzing this problem, and I never made a patch
because I saw no clearly satisfactory solution.) 

I hope this helps.

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