I have been studying the Linux source code of POV-Ray (version that is
posted on web site).
It may be possible to obtain shell or other access to the host's computer by
exploiting bugs in pov's handling of command line parameters. Try this:
give pov a very long command line parameter and it crashes with a
segmentation fault. I am trying to see if this is exploitable, it
probably is.

A possible exploit of this could be to gain access to a computer
running pov as part of a render farm. The command line for pov depends on
the information sent from the server to the client farmer, so an
exploiter could spoof information and gain access to the user's computer.

The problematic file is optin.c

Post a reply to this message

ncryptor wrote:
> 
> I have been studying the Linux source code of POV-Ray (version that is
> posted on web site).
> It may be possible to obtain shell or other access to the host's computer by
> exploiting bugs in pov's handling of command line parameters. Try this:
> give pov a very long command line parameter and it crashes with a
> segmentation fault. I am trying to see if this is exploitable, it
> probably is.
> 
> A possible exploit of this could be to gain access to a computer
> running pov as part of a render farm. The command line for pov depends on
> the information sent from the server to the client farmer, so an
> exploiter could spoof information and gain access to the user's computer.
> 
> The problematic file is optin.c

I must say i don't get it, a render farm (either PVM or some custom
coordination program) starts povray internally, i don't see how you could
'obtain shell or other access'.  If you see a problem, please post an
example where this becomes visible.

Note that being able to execute programs with Post_Scene_Command etc. is a
different topic, but therefore IO-restrictions are introduced in 3.5.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 22 Apr 2002 20:40:05 +0300, Christoph Hormann wrote:


> 
> I must say i don't get it, a render farm (either PVM or some custom
> coordination program) starts povray internally, i don't see how you
> could 'obtain shell or other access'.  If you see a problem, please post
> an example where this becomes visible.
> 
> Note that being able to execute programs with Post_Scene_Command etc. is
> a different topic, but therefore IO-restrictions are introduced in 3.5.
> 
> Christoph
> 

The render farm of some projects, such as IMP, are based on scripts
checking the server for new files, downloading them and running pov with
them. An exploiter could fool the script into running pov with a
command line which will allow access to the user's computer. for example,
the script might think that 'ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ...' is
the file name and try running pov with this command line.
This isn't concrete but a security leak is possible. The pov 3.5 IO
restrictions are do not block this kind of vulerability.

Post a reply to this message

ncryptor wrote:
> 
> [...]
> 
> The render farm of some projects, such as IMP, are based on scripts
> checking the server for new files, downloading them and running pov with
> them. An exploiter could fool the script into running pov with a
> command line which will allow access to the user's computer. for example,
> the script might think that 'ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ...' is
> the file name and try running pov with this command line.
> This isn't concrete but a security leak is possible. 

I have the impression you are just trying to seed some paranoia, unless
you have a concrete example of something going wrong i don't see any
problems.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

ncryptor wrote:
[Snip]
 > A possible exploit of this could be to gain access to a computer running
 > pov as part of a render farm. The command line for pov depends on the
 > information sent from the server to the client farmer, so an exploiter
 > could spoof information and gain access to the user's computer.
 >

Yes, it is possible, but such exploits are usually used with programs,
running under root authority ('suid programs'). Does POV-Ray run under 
root authority? Does it need to run under root authority? I guess that 
in both cases answer is No. So even if someone used such exploit, then 
all he gains, is ordinary user's authority. And renderfarms could limit 
user rights for running POV-Ray to minimum (possibility to read scene 
files and write output file into predefined directory).
[Disclaimer: I'm not expert in Unix/Linux security, so there might be 
something I'm missing.]

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
> I have the impression you are just trying to seed some paranoia, unless
> you have a concrete example of something going wrong i don't see any
> problems.

To be fair to the person who reported the problem, I think it's not
paranoia. Computer security is an important issue these days.

Users of POV-Ray must realise that it is NOT designed to be 'network
safe', and it is NOT designed to take untrusted input. There are
without doubt potential buffer overflows and other various methods
of causing the program to misbehave, given the right set of input
files and/or filenames.

Anyone using POV-Ray in such a way that it accepts input from unknown
persons via the net ought to be very wary, and certainly an installation
of that nature, if it exists, should be run with the minimim privileges
available under the host operating system.

-- Chris

Post a reply to this message

Of course if there is code, allowing buffer overflow, then it should be 
corrected (or is it done already in 3.5?). I took quick look into 
optin.c and it seems that there are indeed some strcpy calls without 
bounds check and some strncpy calls without writing terminator to copy 
string (AFAIK strncpy does not put '\0' to end of copy, if source string 
length is equal or greater than given value).

Post a reply to this message

My point is, like Vahur Krouverk pointed out, that buffer overflows should
be corrected. Who knows what will happen one day - at the least, unchecked
bounds are a big source of hard-to-fix bugs.

POV isn't designed to handle vicious attacks, but it should be protected at
least against itself, which also gains a bit of security.

What i suggest is that ALL the source be checked for buffer overflows and
this be corrected, so that in the final version of 3.5 we will have a
completely stable, secure version. This sounds like a lot of work but i
think its worth it.


"Chris Cason" <new### [at] deletethispovrayorg> wrote in message
news:3cc457b2@news.povray.org...
>
> "Christoph Hormann" <chr### [at] gmxde> wrote in message
> > I have the impression you are just trying to seed some paranoia, unless
> > you have a concrete example of something going wrong i don't see any
> > problems.
>
> To be fair to the person who reported the problem, I think it's not
> paranoia. Computer security is an important issue these days.
>
> Users of POV-Ray must realise that it is NOT designed to be 'network
> safe', and it is NOT designed to take untrusted input. There are
> without doubt potential buffer overflows and other various methods
> of causing the program to misbehave, given the right set of input
> files and/or filenames.
>
> Anyone using POV-Ray in such a way that it accepts input from unknown
> persons via the net ought to be very wary, and certainly an installation
> of that nature, if it exists, should be run with the minimim privileges
> available under the host operating system.
>
> -- Chris
>
>
>
>

Post a reply to this message

In article <3cc46d7e@news.povray.org> , "ncryptor" <o### [at] ocom> wrote:

> What i suggest is that ALL the source be checked for buffer overflows and
> this be corrected, so that in the final version of 3.5 we will have a
> completely stable, secure version. This sounds like a lot of work but i
> think its worth it.

You are free to do it when the source code is released :-)

I do not agree with you that any final release POV-Ray should be checked to
such an extend for buffer overflows.  I am not saying they should not be
corrected if they cause real problems, but POV-Ray is not intended to be run
in such a way that it has to be assumed to be absolutely secure.

Or, more precisely:  This task will definitely never make it high on the list
for POV-Ray 3.x as it is essentially a waste of time considering there will be
a rewrite with POV-Ray 4.0 anyway.  Even then I doubt it will be a primary
priority.

    Thorsten

Post a reply to this message