[3135] in bugtraq
Re: Possible bufferoverflow condition in lpr, xterm and xload
daemon@ATHENA.MIT.EDU (Mike Acar)
Tue Aug 13 13:55:37 1996
Date: Tue, 13 Aug 1996 09:25:03 -0400
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: Mike Acar <mike@contract.kent.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <Pine.LNX.3.91.960813004759.24815B-100000@garrison.inetcan.net>
from "Digital Dreamer" at Aug 13, 96 00:49:16 am
> The fact that it's in the -display variable, which isn't handled by
> the program but rather the X toolkit it was compiled with, implies
> that this could be a problem with all X programs using this particular
> toolkit. I'm pretty sure Xterm is compiled with the Athena set, which
> is (I beleive) the most common library, followed by Mosaic.
>
> dreamer
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.
Speaking of suid binaries, *why* are /bin/mount and /bin/umount suid?
These shouldn't be run by anybody but the superuser.
It might be worth noting that when I ran tiger on my bastardized and
upgraded Red Hat 2.0 system, it produced a 7 MB output. Mostly this was
complaining about lots of things being group bin, root, etc writable. Or
perhaps this is no surprise to anybody. To Red Hat's credit, none of the
s[ug]id binaries they provide is writable by anybody but the owner.
--
DZ-015 (Mike Acar) Information Retrieval Ministry of Information
