s-povray has some buffer overflow bugs.  This is especially problematic
as it needs to be run by or as root (this is a limitation of svgalib). 
The previous install script and the makefile's install target made this
program suid root.  This opens up potential security holes which someone
might be able to use to gain root access.  For the time being, I'm
recommending people change it so that it can only be run by root. 
Instructions are as follows:

The diagnosis:
Run the following as root:
find / \(-perm -004000 -name s-povray \) -print
If it finds any, you might want to fix them.

The fix:
Run the following as root:
chmod 0755 /usr/local/bin/s-povray
(modify the path if it was installed elsewhere)

There's a new povlinux.tgz and povuni_s.tgz available for download that
no longer installs s-povray suid.  At this point, I'm not going to
promise a fix to the buffer overflows before 3.5.  I have not been able
to exploit the buffer overflow bugs, but that's not exactly my area of
expertise, so that doesn't mean much.  In case anyone is wondering, the
shell-out functionality doesn't appear to open any gaping holes, even if
s-povray is running as root.

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> recommending people change it so that it can only be run by root.

How much will this help?
If you receive an evil scene, you either run it with the suid
version, or you su manually and run it as root. In both cases,
the same harm will be done.

The only difference is to avoid attacks by the user himself,
which is hard anyway if he has physical access to the machine.

Ralf

Post a reply to this message

Ralf Muschall wrote:
> 
> Mark Gordon wrote:
> 
> > recommending people change it so that it can only be run by root.
> 
> How much will this help?
> If you receive an evil scene, you either run it with the suid
> version, or you su manually and run it as root. In both cases,
> the same harm will be done.
> 
> The only difference is to avoid attacks by the user himself,
> which is hard anyway if he has physical access to the machine.
> 
> Ralf

The real risk is that someone should get access to a user account on
your machine and use this exploit to parlay it into root access. 
Similarly, if there are several users on your machine, one such user
could potentially use this to gain root access.

If you're the only person who uses your machine, and you're not worried
about possible remote exploits, it's not such a big deal.

-Mark Gordon

Post a reply to this message