Mark Wagner <mar### [at] gtenet> wrote:
: Along these lines, it *is* possible to write a POV-Ray virus that infects
: POV scene files.  However, as things stand right now, the incredible disk
: thrashing that would occur as the virus tries to find files to infect would
: clue anyone in to what is happening.

  I can't think of any way to do this (at least with the official povray).
Can you explain me?

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

Post a reply to this message

On 20 Oct 1999 07:58:48 -0400, Nieminen Juha wrote:
>  With povray itself it may be impossible, but I was also thinking that it
>could be a povwin virus which could use some features of the windows
>version (like codemax macros). But I haven't discovered any way yet.
>  Does anyone have any idea (Ron?).

I don't know how you'd do it either.  The hard part would be finding files
to infect, as you said, since POV has no facility for reading directories.
The only way I can think it would work is if there were some way for the 
currently running script to get its own name, then read itself and look
for #includes and infect them in the hopes that they'd be shared with other
script files, but two things make that unlikely:  First, a script can't get
its own name.  Second, #read isn't very flexible about what it accepts.  So
I don't see any way to write a POV-only virus.  

Of course you could write a script that created a shell script to do the 
dirty deed and stuck it in your .login, but that isn't pure POV.  You could
also write one that puts itself in the insert menu on Windows, but I think 
that one wouldn't live very long.

One that could live a while and would be pretty close to POV-only would be
a script that adds a shellout to a standard INI file.  That shellout could
then infect the currently-rendering script file.  This still isn't cross-
platform due to the differences in shell syntax and standard commands.

Post a reply to this message

Yes, yes. Of course. I just don't think this functionality should be excluded
because of the (not so serious) security risk.
Some measures mihgt be prudent. Perhaps have the user explicitly allow the usage
of #exec with a command line switch, which _cannot_ be invoked via an ini file.

Margus

Nieminen Juha wrote:
> 
>   The fact that the possibility of a malicious file is very small, that
> doesn't mean that we shouldn't take into account some security issues.
> Let's do it before something happens. It's better than doing it afterwards.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Remco de Korte <rem### [at] xs4allnl> wrote:
> 
>   It's very difficult to achieve this kind of prompting with ANSI C.

I don't think that'd very good of ANSI C then ;)

>   It also would be extremely tedious if you would need to answer to a
> prompt every time you render your own scene.

The way it is now with the filesaving in the Windows version seems like a good
way. When rendering a file you're prompted whether you want to save the changes
(while at the same time it will overwrite any file you made changes to at the
moment you want to change it under another name - but that's another topic). At
that point you can choose to disable that prompt for the duration of that
session. I must admit that it is a bit tedious at times but on the other hand
it's a safety measure. 

Come to think of it: how about an overal 'condom'-mode?  

Remco

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote in message
news:380E13A6.2D08E62E@xs4all.nl...
> The way it is now with the filesaving in the Windows version seems like a
good
> way. When rendering a file you're prompted whether you want to save the
changes
> (while at the same time it will overwrite any file you made changes to at
the
> moment you want to change it under another name - but that's another
topic). At
> that point you can choose to disable that prompt for the duration of that
> session. I must admit that it is a bit tedious at times but on the other
hand
> it's a safety measure.

But there is no 'session' in the command line versions of POV, each
execution is independent from the last.

Post a reply to this message

Edward Coffey wrote:
> 
> Remco de Korte <rem### [at] xs4allnl> wrote in message
> news:380E13A6.2D08E62E@xs4all.nl...
> > The way it is now with the filesaving in the Windows version seems like a
> good
> > way. When rendering a file you're prompted whether you want to save the
> changes
> > (while at the same time it will overwrite any file you made changes to at
> the
> > moment you want to change it under another name - but that's another
> topic). At
> > that point you can choose to disable that prompt for the duration of that
> > session. I must admit that it is a bit tedious at times but on the other
> hand
> > it's a safety measure.
> 
> But there is no 'session' in the command line versions of POV, each
> execution is independent from the last.

By a session you could also mean a batch of files to be rendered or an
animation.

Remco

Post a reply to this message

Nieminen Juha wrote in message <380daf31@news.povray.org>...
>Mark Wagner <mar### [at] gtenet> wrote:
>: Along these lines, it *is* possible to write a POV-Ray virus that infects
>: POV scene files.  However, as things stand right now, the incredible disk
>: thrashing that would occur as the virus tries to find files to infect
would
>: clue anyone in to what is happening.
>
>  I can't think of any way to do this (at least with the official povray).
>Can you explain me?


I have a virus that will run (almost) in standard POV-Ray.  Should I post
it?

While developing this virus, I found a bug in POV-Ray's string handling
routines -- sometimes a sequence such as "\"\\\\\",\"\\\"\"," will be
incorrectly written to a file.

Mark

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote:
: The way it is now with the filesaving in the Windows version seems like a good
: way. When rendering a file you're prompted whether you want to save the changes
: (while at the same time it will overwrite any file you made changes to at the
: moment you want to change it under another name - but that's another topic). At
: that point you can choose to disable that prompt for the duration of that
: session. I must admit that it is a bit tedious at times but on the other hand
: it's a safety measure. 

  You can't do this with ANSI C (nor C++).

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

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: I have a virus that will run (almost) in standard POV-Ray.  Should I post
: it?

  I think it's safe. A povray virus can never hide himself since you can
always see your pov-files. On the other hand non-advanced users will be
too frightened to render the infected scene when they see the word "virus",
so there shouldn't be any problem there.
  The code would be extremely interesting.

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

Post a reply to this message

I don't think it's that difficult to create a #exec functionality that would
be safe. The solution might be:

1. A kind of register in POV of which commands are allowed. When  a scene
file with a binary executable is distributed, one should manually tell
povray that this file is ok to run, for example via an "registered #exec
programs" dialog from the menu, and *not* via an .INI-file.

2. Only allow executables whose filename begin with "pvex_" or similar. Of
course you can create a program that simply formats your hard drive and call
it "pvex_cool_diamond".

3. Never allow system commands.

I think the first solution is the best. What do you think? It shouldn't be
that difficult to include an #exec command in the official?

Bu then comes the problem with different platforms. In my opinion, *all*
povray users should be able to run *any* source file and obtain the *same*
results as everybody. If I create my own c++-compiler for SIMENOS2000 and
compile PovRay, I should be able to run the binary executables included with
the source file... But then, again, I might not create this operating
system.

Simen.

Post a reply to this message