Re: Possible bufferoverflow condition in lpr, xterm and xload

[mike () contract kent edu (Mike Acar)]

> 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