[3167] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Possible bufferoverflow condition in lpr, xterm and xload

daemon@ATHENA.MIT.EDU (Christopher Masto)
Wed Aug 14 19:10:56 1996

Date: 	Wed, 14 Aug 1996 09:51:26 -0400
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: Christopher Masto <exidor@superior.net>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To:  <199608131325.JAA21033@denali.contract.kent.edu> from "Mike Acar"
              at Aug 13, 96 09:25:03 am

> s/Mosaic/Motif/
> xterm is indeed linked with libXaw... Along with a bunch of other
> libraries. But the display environment variable is handled, I think, by
> the X Intrinsics toolkit, libXt. If both xload and xterm behave the same
> way, then chances are the bug's in the library. I don't know how close
> the XFree86 implmentation of libXt is, but this *may* be a bug inherited
> from MIT's distribution. A quick check of SGI's xterm and xload show
> that a DISPLAY variable that's 8192 bytes doesn't cause them any grief.
> On the other hand, SGI could have totally rewritten X. I wouldn't put it
> past them.

nimbus:~$ a='gibberish'
nimbus:~$ for i in 1 2 3 4 5 6 7 8 9 10 11 12; do a=$a$a; done
nimbus:~$ echo $a | wc -c
   36865
nimbus:~$ xterm -display $a
Bus error
nimbus:~$ uname -sr
FreeBSD 2.1.5-RELEASE
--
Christopher Masto

home help back first fref pref prev next nref lref last post