Simon Lemieux wrote:
> 
> Hi,
>         I was wondering, what are all the issues a hacker would have to hack my
> computer if he gave me a few files.gif, file.pov and file.ini to render?
> 
> I know in the file.ini there are (from man povray)
>        Pre_Scene_Return=return action
>        Pre_Frame_Return=return action
>        Post_Scene_Return=return action
>        Post_Frame_Return=return action
>       User_Abort_Return=return action
>        Fatal_Error_Return=return action
> 
> is there such thing in a file.pov? or is there something else in the file.ini???

There has been quite a long thread about this issues a few months
(weeks) ago. Warp and Ron gave good ideas.
IMHO memory and disk consumption are issues.
If you make a scene featuring an infinite loop adding objects to an
union, you will have POV crash after running out of memory.
Unfortunately it is likely that some other processes die to, including
system services.
If you open a file and write to it in an infinite loop, you can fill
your disk completly, which can be harmful in some cases (under Un*x,
filling /tmp or /var can have odd consequences). Even if you suppress
user I/O, one can still decide to render a nearly empty scene (for
speed) at a huge resolution: 65536*65536*24bpp takes 1.5 Gb...

For these reasons I would suggest you use process limitations, such as
ulimit and quotas under Un*x.

-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

> You don't have to know how it's done to avoid it. :)

And what if... I want to know... if there are security problems in povray, I
need to know them...  You might have seen on povray.general that I've started
working on an utility for povray... well, that's why I would need these security
informations.

> Your best bet is to run povray as a user with privileges only to write in
> a specific directory and no login privileges.  For extra security, you
> might also use chroot.

What if I'm not on linux but on Windows? what about MacOS? what about the newer
MacOS X?

Thanks,
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

> There has been quite a long thread about this issues a few months
> (weeks) ago. Warp and Ron gave good ideas.
> IMHO memory and disk consumption are issues.
> If you make a scene featuring an infinite loop adding objects to an
> union, you will have POV crash after running out of memory.
> Unfortunately it is likely that some other processes die to, including
> system services.
> If you open a file and write to it in an infinite loop, you can fill
> your disk completly, which can be harmful in some cases (under Un*x,
> filling /tmp or /var can have odd consequences). Even if you suppress
> user I/O, one can still decide to render a nearly empty scene (for
> speed) at a huge resolution: 65536*65536*24bpp takes 1.5 Gb...
> 
> For these reasons I would suggest you use process limitations, such as
> ulimit and quotas under Un*x.

Thanks, I already thought about this... that's why I asked a survey on
povray.general...  to do a manual limitation... and my program could parse the
file and check it to see if there is no loop or anything...

Thanks,
	Simon


-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

On Thu, 16 Nov 2000 17:15:39 -0500, Simon Lemieux wrote:
>> You don't have to know how it's done to avoid it. :)
>
>And what if... I want to know... if there are security problems in povray, I
>need to know them...  You might have seen on povray.general that I've started
>working on an utility for povray... well, that's why I would need these security
>informations.

Well, then...

You probably need to make sure the script doesn't do any #fopens or #writes,
and make sure the output filename specified in the .ini file is okay (or remove
it entirely and replace it with a filename you make up.)  That'll be good
enough to catch most problems.  Watch for weird parser stuff like the fact
that this is valid syntax:

                                                 #

    fopen (whatever)


>What if I'm not on linux but on Windows? what about MacOS? what about the newer
>MacOS X?

MacOS X is of course BSD-based, so should support things like permissions and
chroot.  The other two aren't server operating systems, and running server
processes on them is just asking for trouble.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Thu, 16 Nov 2000 17:20:32 -0500, Simon Lemieux wrote:
>> There has been quite a long thread about this issues a few months
>> (weeks) ago. Warp and Ron gave good ideas.
>> IMHO memory and disk consumption are issues.
>> If you make a scene featuring an infinite loop adding objects to an
>> union, you will have POV crash after running out of memory.
>> Unfortunately it is likely that some other processes die to, including
>> system services.
>> If you open a file and write to it in an infinite loop, you can fill
>> your disk completly, which can be harmful in some cases (under Un*x,
>> filling /tmp or /var can have odd consequences). Even if you suppress
>> user I/O, one can still decide to render a nearly empty scene (for
>> speed) at a huge resolution: 65536*65536*24bpp takes 1.5 Gb...
>> 
>> For these reasons I would suggest you use process limitations, such as
>> ulimit and quotas under Un*x.
>
>Thanks, I already thought about this... that's why I asked a survey on
>povray.general...  to do a manual limitation... and my program could parse the
>file and check it to see if there is no loop or anything...

No it can't.  That's a famous theorem by from Computer Science, called the 
Halting Problem.  It's insoluble.  (Unless you plan to forbid loops entirely, 
in which case it'll be pretty useless.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

> You probably need to make sure the script doesn't do any #fopens or #writes,
> and make sure the output filename specified in the .ini file is okay (or remove
> it entirely and replace it with a filename you make up.)  That'll be good
> enough to catch most problems.  Watch for weird parser stuff like the fact
> that this is valid syntax:

Thanks!

>                                                  #
> 
>     fopen (whatever)

Hmmm... is this "<many_spaces>#fopen (whatever" 
or "<many_spaces>#\n\n fopen (whatever)"?

> >What if I'm not on linux but on Windows? what about MacOS? what about the newer
> >MacOS X?
> 
> MacOS X is of course BSD-based, so should support things like permissions and
> chroot.  The other two aren't server operating systems, and running server
> processes on them is just asking for trouble.

I know about MacOS X... and for the other two... well, I wont need
permissions...  The programm will handle that all by itself.. 

Thanks a lot!
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

> No it can't.  That's a famous theorem by from Computer Science, called the
> Halting Problem.  It's insoluble.  (Unless you plan to forbid loops entirely,
> in which case it'll be pretty useless.)

Hmm... true... anyway I don't wish to work on this...  but my program should be
able to deal with that kind of situations....  Believe me!  ;)

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

On Thu, 16 Nov 2000 17:37:03 -0500, Simon Lemieux wrote:
>> You probably need to make sure the script doesn't do any #fopens or #writes,
>> and make sure the output filename specified in the .ini file is okay (or remove
>> it entirely and replace it with a filename you make up.)  That'll be good
>> enough to catch most problems.  Watch for weird parser stuff like the fact
>> that this is valid syntax:
>
>Thanks!
>
>>                                                  #
>> 
>>     fopen (whatever)
>
>Hmmm... is this "<many_spaces>#fopen (whatever" 
>or "<many_spaces>#\n\n fopen (whatever)"?

It's "<any whitespace>#<any whitespace>fopen<any whitespace>(whatever)"
Where "any whitespace" is any combination of spaces, tabs, CRs, and LFs.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <3A145C8B.373F10E2@yahoo.com> , Simon Lemieux 
<lem### [at] yahoocom>  wrote:

> what about MacOS? what about the newer MacOS X?

On Mac OS you can look the System and Application folder, but that is it.
People could probably read and write to any other file and destroy them that
way, but as there is no login there is no break-in and they can't destroy or
change the system.

As for Mac OS X, as Ron said, it is BSD-based with a non-X GUI, so all the
Unix tricks work just fine.  However, in theory it should be easy to set up
a next to no privileges user thanks to the GUI.  Anyway, Mac OS X is not
final, and Mac OS X Server costs a lot of money (for non-developers)...


   Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Simon Lemieux wrote in message <3A1432A7.2BA5CE7C@yahoo.com>...
>Hi,
> I was wondering, what are all the issues a hacker would have to hack my
>computer if he gave me a few files.gif, file.pov and file.ini to render?


If you are running an old version of the SuperPatch, watch out for #exec
commands in the .pov and .ini files.  Also, check to make sure that the
scene files are not #including files that they shouldn't (such as your
password file).

--
Mark

Post a reply to this message