POV-Ray : Newsgroups : povray.programming : Hackers... (Howto "not being hacked with povray") Server Time
28 Jul 2024 14:19:12 EDT (-0400)
  Hackers... (Howto "not being hacked with povray") (Message 1 to 10 of 44)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Simon Lemieux
Subject: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 13:15:26
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?

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???

This information is Very important to me!


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


Post a reply to this message

From: Warp
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 14:02:19
Message: <3a142f3b@news.povray.org>
It is possible to open a file for writing (and then write something in
there) within the .pov file.
  This can be used to write (or overwrite) system files, configuration
files, login files and so on.
  For example, if you are using dos/windows povray, the .pov file, when
povray is parsing it, could open your autoexec.bat and put some nasty
commands at the end of it (such as deltree...). In unix accounts it can
write nasty commands to your .login file and other similar user files (if
you are running povray with your own account privileges).

  Note also that the .ini file could specify an important system/user file as
the output image file for povray (that is, povray would overwrite the file
when writing the image). This can be quite dangerous specially in dos/windows.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Simon Lemieux
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 14:08:40
Message: <3A143F21.35CC9A4A@yahoo.com>
>   It is possible to open a file for writing (and then write something in
> there) within the .pov file.
>   This can be used to write (or overwrite) system files, configuration
> files, login files and so on.
>   For example, if you are using dos/windows povray, the .pov file, when
> povray is parsing it, could open your autoexec.bat and put some nasty
> commands at the end of it (such as deltree...). In unix accounts it can
> write nasty commands to your .login file and other similar user files (if
> you are running povray with your own account privileges).
> 
>   Note also that the .ini file could specify an important system/user file as
> the output image file for povray (that is, povray would overwrite the file
> when writing the image). This can be quite dangerous specially in dos/windows.

Interesting... that's exactly what I was looking for... do you know how it is
done?  So I can know how to avoid it?


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


Post a reply to this message

From: Ron Parker
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 15:03:30
Message: <slrn918fcl.8fs.ron.parker@fwi.com>
On Thu, 16 Nov 2000 15:10:09 -0500, Simon Lemieux wrote:
>Interesting... that's exactly what I was looking for... do you know how it is
>done?  So I can know how to avoid it?

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

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.

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


Post a reply to this message

From: Francois Dispot
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 16:07:00
Message: <3A144C71.E4522224@club-internet.fr>
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

From: Simon Lemieux
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 16:14:08
Message: <3A145C8B.373F10E2@yahoo.com>
> 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

From: Simon Lemieux
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 16:19:12
Message: <3A145DB0.D5410C1C@yahoo.com>
> 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

From: Ron Parker
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 16:20:50
Message: <slrn918jtk.8j4.ron.parker@fwi.com>
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

From: Ron Parker
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 16:23:15
Message: <slrn918k24.8j4.ron.parker@fwi.com>
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

From: Simon Lemieux
Subject: Re: Hackers... (Howto "not being hacked with povray")
Date: 16 Nov 2000 16:35:32
Message: <3A14618F.359BF13E@yahoo.com>
> 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

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.