Hello There.

I have an online povray rendering farm and I happened to be the victim
of a "hack" attempt already with it.  The user was quite intelligent and
used povray macros to edit my .login an .cshrc files on my machine. 
<pout>  It actually worked and started to delete stuff, but thankfully I
caught it in time and saved everything.  So, kudos to whomever wrote it,
but in the future, I'd like to stop those types of attacks if possible.

Anyway, I'd like to bring the farm back online, but in order to do so, I
need to know if it's possible to remove the ability to do #fopen's and
#write's via the command line or something like that.  I don't want to
disable #macros because they're a powerful part of the povray 3.1
language, but I do want to make the renderer a little more secure.

Does anyone know?  I'm using povray 3.1g.

- Steve

--
EMAIL: (h) ste### [at] badcheesecom  WEB: http://badcheese.com/~steve
       (w) swe### [at] rapucaredu
           ste### [at] mailcom

Post a reply to this message

In article <3A107E60.BE067E87@rap.ucar.edu>, Space Dude 
<swe### [at] rapucaredu> wrote:

> I have an online povray rendering farm and I happened to be the victim
> of a "hack" attempt already with it.  The user was quite intelligent and
> used povray macros to edit my .login an .cshrc files on my machine. 

Ouch. I would have liked to think the POV community was above this sort 
of thing...recent posts show otherwise, though. :-(


> Anyway, I'd like to bring the farm back online, but in order to do so, I
> need to know if it's possible to remove the ability to do #fopen's and
> #write's via the command line or something like that.  I don't want to
> disable #macros because they're a powerful part of the povray 3.1
> language, but I do want to make the renderer a little more secure.

I notice you are on Linux...can't you just restrict access to those 
files?

I think you would only need to disable #write, but you can't do it by 
the command line or .ini file in 3.1g or current MegaPOV. It would be 
very easy to cripple it's functionality by modifying the source, making 
a version that has this as an option would be a bit more difficult.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> In article <3A107E60.BE067E87@rap.ucar.edu>, Space Dude
> <swe### [at] rapucaredu> wrote:
> 
> > I have an online povray rendering farm and I happened to be the victim
> > of a "hack" attempt already with it.  The user was quite intelligent and
> > used povray macros to edit my .login an .cshrc files on my machine.
> 
> Ouch. I would have liked to think the POV community was above this sort
> of thing...recent posts show otherwise, though. :-(
> 
> > Anyway, I'd like to bring the farm back online, but in order to do so, I
> > need to know if it's possible to remove the ability to do #fopen's and
> > #write's via the command line or something like that.  I don't want to
> > disable #macros because they're a powerful part of the povray 3.1
> > language, but I do want to make the renderer a little more secure.
> 
> I notice you are on Linux...can't you just restrict access to those
> files?
> 
> I think you would only need to disable #write, but you can't do it by
> the command line or .ini file in 3.1g or current MegaPOV. It would be
> very easy to cripple it's functionality by modifying the source, making
> a version that has this as an option would be a bit more difficult.
> 
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
> 
>

Ok, I suppose that I should just write a script for grep for #write
before rendering, huh?  I shoulda just thought of that.  Ok.  That's
cool.  Thanks!

- Steve
--
EMAIL: (h) ste### [at] badcheesecom  WEB: http://badcheese.com/~steve
       (w) swe### [at] rapucaredu
           ste### [at] mailcom

Post a reply to this message

In article <3A10A018.A2AB62BE@rap.ucar.edu> , Space Dude 
<swe### [at] rapucaredu>  wrote:

>
> Ok, I suppose that I should just write a script for grep for #write
> before rendering, huh?  I shoulda just thought of that.  Ok.  That's
> cool.  Thanks!

When doing that, be aware that something like this is also valid:

#      write(.....)

and you may want to play around with it a bit to find out what else is or is
not valid.


     Thorsten

Post a reply to this message

Space Dude wrote:

> I have an online povray rendering farm and I happened to be the victim
> of a "hack" attempt already with it.  The user was quite intelligent and
> used povray macros to edit my .login an .cshrc files on my machine.
> <pout>  It actually worked and started to delete stuff, but thankfully I
> caught it in time and saved everything.  So, kudos to whomever wrote it,
> but in the future, I'd like to stop those types of attacks if possible.

It was IMBJR!
(kidding, kidding)

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

On Mon, 13 Nov 2000 16:50:56 -0700, Space Dude wrote:
>Anyway, I'd like to bring the farm back online, but in order to do so, I
>need to know if it's possible to remove the ability to do #fopen's and
>#write's via the command line or something like that.  I don't want to
>disable #macros because they're a powerful part of the povray 3.1
>language, but I do want to make the renderer a little more secure.

You might try either modifying the source code to disable the ability to
do #write (and #fopen) or you might try just using chroot and/or file 
permissions to restrict where the POV process is allowed to write.

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

Post a reply to this message

Hey!

Thanks for all of the input - All of the suggestions were very useful
and I'm proud to say that the povray renderer is back up and running and
should be much more hacker-proof!

http://www.badcheese.com/~steve/povray_form.shtml

P.S. I've added a few more more powerful machines to the farm so people
may feel happy to pound away.

- Steve

--
EMAIL: (h) ste### [at] badcheesecom  WEB: http://badcheese.com/~steve
       (w) swe### [at] rapucaredu
           ste### [at] mailcom

Post a reply to this message

"Space Dude" <swe### [at] rapucaredu> wrote in message
news:3A1### [at] rapucaredu...

As a couple of extra suggestions:

1. Couldn't you institute a password/login?

2. Couldn't you search (and strip) the incoming pov script for fopen etc.?

Post a reply to this message

Space Dude wrote:
 
> I have an online povray rendering farm and I happened to be the victim
> of a "hack" attempt already with it.  The user was quite intelligent and
> used povray macros to edit my .login an .cshrc files on my machine.
> <pout>  It actually worked and started to delete stuff, but thankfully I
> caught it in time and saved everything.  So, kudos to whomever wrote it,
> but in the future, I'd like to stop those types of attacks if possible.

Initial reactions:

1) It sounds like POV-Ray was running as your user from some sort of
remotely executable script.  If you're going to do something like that,
run it as a special user made expressly for the purpose, perhaps even
one who can't log in. 

2) It's not a bad idea to have it run within chroot.  That makes it
harder to clobber any files outside its isolated little sandbox (avoid
the myriad /tmp races, for instance, as well as keeping it out of your
own personal ~).  Give it a little piece of your filesystem to call home
and put everything it needs there.

I'm not sure how your rendering farm is set up, so I can't be much more
specific in my advice.

-Mark Gordon

Post a reply to this message

> 
> -Mark Gordon

	Hey ! Mark is back :-)
	How was your moving ? Hope all was fine for you.
	Well, are we now almost able to use the "official" unofficial
MegaPOV for UNIX/Linux ? {hehehehehe}
	Glad to *see* you again on n.p.o !


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message