 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was looking through Ken's links and ended up in this page:
http://www.io.com/~wwagner/pov.html
I would want to seriously warn about this #exec patch (specially
because povray 3.5 might include it).
Povray is currently quite safe to use. You can download a .pov file and
render it with povray and the only harm it can do is to create an image
file. It just can't do anything else. You can safely render a 10000 lines
long pov file without having to worry about what does it contain.
However, if this #exec patch is included as is, this security ends there.
A malicious person can easily do harm to imprudent people. They can easyly
add somewhere at the line 5000 of the previous code commands like:
#exec "deltree /y c:\\"
#exec "rm -rf /"
An advanced user could search the file for #exec commands but the malicious
person could still cause harm by adding hundreds of harmless and necessary
#exec commands to the file. Searching for dangerous ones among them could be
a hard job. (Searching for "del", "deltree" or "rm" may not be enough because
you can make harm with lots of other ways; you can also form those words
by concatenating letters so searching is impossible...)
So even advanced users are not completely safe (the only way to be completely
sure is not to render any scene with #exec commands; but that could be
sometimes too limiting).
Now, thinking about it... Even searching for "#exec" is not enough, since
you can form that word by concatenating letters, write it to a file and then
#include it in the scene.
As we can see, there's no 100% secure way to detect dangerous files.
Of course the #exec command could be very useful (specially with unix
shells). Hoever, it should NOT be included as is, without any security
issues.
I don't know if there's any safe way to include it into povray. The only
thing I can think of is that by default povray will not execute the #exec
commands (it may issue a warning instead, for example) and if you really
want them to work, you have to say it with a command line switch or an
.ini file entry.
However, this can only cause that people put that entry in their povray.ini
and there we have a disaster waiting to occur. So it's not a perfect solution.
I can't think of any perfect solution. The only perfect solution would be
not adding the #exec command to povray.
Comments?
--
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:
>
> I was looking through Ken's links and ended up in this page:
> http://www.io.com/~wwagner/pov.html
>
> I would want to seriously warn about this #exec patch (specially
> because povray 3.5 might include it).
>
> Povray is currently quite safe to use. You can download a .pov file and
> render it with povray and the only harm it can do is to create an image
> file. It just can't do anything else. You can safely render a 10000 lines
> long pov file without having to worry about what does it contain.
Anyone of you programmers could easily build a malicious program,
call it a povray utility, and there is nothing keeping you from
causing irreparable damage to someone else's system if they use
it. One can only hope that no one will ever produce such a utility
but the possibility is there. You must also have the same faith you
have in any software you try that something similar won't be tried
by a "malicious" pov scene designer.
Even considering the harm that it can do also think of the
possibilities. It adds a whole new avenue to external processes
that are impossible to do now with simple Pov script. One such
use would be calls to the system clock for true random animation
scene development. Other possibilities would be calling external
executables that have pov scene output, passing it command line
parameters from inside pov, and then parse the file it produced.
It would save a lot of steps if you could do all of your development
work from within Pov without having to operate outside the scene
editing environment.
I'm not saying your concerns are invalid but the benefits would
likewise be enormous.
--
Ken Tyler - 1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I also would prefer if this patch would *NOT* be included in 3.5. I
didn't know that this patch existed and I will for sure not use it!
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Nieminen Juha wrote:
> >
Risks and benefits. I don´t know about any other platform then DOS or Windows,
but for simple cases I think #exec could be done with a batch/file of some sort.
If incorporated in POV I think the best way to avoid problems is to always
prompt before execution, as is done with overwriting files and other things that
may cause "regret".
As far as I can imagine the POV-team have already considered this issue.
It`s good to stay alert though, as a real POV-scout.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'd never heard of this patch, and much less that it was going into 3.5.
Please cut it out, I don't care how many benefits this thing gives us. We'll
just have to find another way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19 Oct 1999 05:13:14 -0400, Nieminen Juha wrote:
> I was looking through Ken's links and ended up in this page:
>http://www.io.com/~wwagner/pov.html
>
> I would want to seriously warn about this #exec patch (specially
>because povray 3.5 might include it).
>
> Povray is currently quite safe to use. You can download a .pov file and
>render it with povray and the only harm it can do is to create an image
>file. It just can't do anything else. You can safely render a 10000 lines
>long pov file without having to worry about what does it contain.
>
> However, if this #exec patch is included as is, this security ends there.
>A malicious person can easily do harm to imprudent people. They can easyly
>add somewhere at the line 5000 of the previous code commands like:
>#exec "deltree /y c:\\"
>#exec "rm -rf /"
Whoa, better not tell y'all about Dan Connelly's #system patch that's been
part of the superpatch since the beginning, then, huh? Though I'd be
interested in knowing where you heard that 3.5 would include this #exec
patch - this is the first time I've ever heard about it.
Seriously, folks, consider this:
#fopen FILE "c:\\autoexec.bat" append
#write FILE "attrib -r -h -s c:\\windows\\system.dat\n"
#write FILE "del c:\\windows\\system.dat\n"
#fclose FILE
Too obvious for you? What if I wrote it a character at a time to an .inc
file using commands scattered throughout the code to my 10000 line scene
file, then included the .inc file?
And what if the animation you're rendering comes with an INI file? Are
you going to remember to check the shellouts in the INI file?
The point is, if you don't trust the source of a file, don't run it. Getting
an unknown POV script over the Internet is just as dangerous as getting C
source code or Perl source code or source code in any other programming
language, because that's what it is.
On the other hand, I can see where it would be nice if there were a command-
line switch to disable the file i/o commands and anything else you might
consider dangerous when rendering something questionable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok with you! But I think that new user MUST know the risk of using script of
other user! Because it is not obvious for all user (I think) that the script of
povray is so powerful and can cause dammage to the system! So post some remark
like these ones to the general group and newuser group!
Fabian.
Ron Parker wrote:
> On 19 Oct 1999 05:13:14 -0400, Nieminen Juha wrote:
> > I was looking through Ken's links and ended up in this page:
> >http://www.io.com/~wwagner/pov.html
> >
> > I would want to seriously warn about this #exec patch (specially
> >because povray 3.5 might include it).
> >
> > Povray is currently quite safe to use. You can download a .pov file and
> >render it with povray and the only harm it can do is to create an image
> >file. It just can't do anything else. You can safely render a 10000 lines
> >long pov file without having to worry about what does it contain.
> >
> > However, if this #exec patch is included as is, this security ends there.
> >A malicious person can easily do harm to imprudent people. They can easyly
> >add somewhere at the line 5000 of the previous code commands like:
> >#exec "deltree /y c:\\"
> >#exec "rm -rf /"
>
> Whoa, better not tell y'all about Dan Connelly's #system patch that's been
> part of the superpatch since the beginning, then, huh? Though I'd be
> interested in knowing where you heard that 3.5 would include this #exec
> patch - this is the first time I've ever heard about it.
>
> Seriously, folks, consider this:
>
> #fopen FILE "c:\\autoexec.bat" append
> #write FILE "attrib -r -h -s c:\\windows\\system.dat\n"
> #write FILE "del c:\\windows\\system.dat\n"
> #fclose FILE
>
> Too obvious for you? What if I wrote it a character at a time to an .inc
> file using commands scattered throughout the code to my 10000 line scene
> file, then included the .inc file?
>
> And what if the animation you're rendering comes with an INI file? Are
> you going to remember to check the shellouts in the INI file?
>
> The point is, if you don't trust the source of a file, don't run it. Getting
> an unknown POV script over the Internet is just as dangerous as getting C
> source code or Perl source code or source code in any other programming
> language, because that's what it is.
>
> On the other hand, I can see where it would be nice if there were a command-
> line switch to disable the file i/o commands and anything else you might
> consider dangerous when rendering something questionable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] fwi com> wrote:
:> (specially because povray 3.5 might include it).
: Whoa, better not tell y'all about Dan Connelly's #system patch that's been
: part of the superpatch since the beginning, then, huh? Though I'd be
: interested in knowing where you heard that 3.5 would include this #exec
: patch - this is the first time I've ever heard about it.
I didn't say that it will include it. I said that it might include it.
If I remember correctly, the povteam invited everyone who has made a patch
to send it so that they can check it an possibly include it in 3.5.
On the other hand, if that #system command you talk about is the equivalent
to the #exec command, then we already have the problem in the superpatch.
: #fopen FILE "c:\\autoexec.bat" append
: #write FILE "attrib -r -h -s c:\\windows\\system.dat\n"
: #write FILE "del c:\\windows\\system.dat\n"
: #fclose FILE
: Too obvious for you? What if I wrote it a character at a time to an .inc
: file using commands scattered throughout the code to my 10000 line scene
: file, then included the .inc file?
Damn, you are right. I never thought about this.
: On the other hand, I can see where it would be nice if there were a command-
: line switch to disable the file i/o commands and anything else you might
: consider dangerous when rendering something questionable.
Since we obviously already have the security problem, I would say that this
is a good idea.
With #system/#exec it may be a good idea what I suggested earlier: you
have to specify a command line switch to enable it.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, I hope that my (perhaps a little bit paranoid) article helped at least
a bit so that people could be more cautious on what they render, specially
if you don't know the source of the file.
And I thought that raytracing was a safe hobby... :)
--
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:
>
> Btw, I hope that my (perhaps a little bit paranoid) article helped at least
> a bit so that people could be more cautious on what they render, specially
> if you don't know the source of the file.
>
> And I thought that raytracing was a safe hobby... :)
If any of those infamous POV-Ray Bulgarian hackers hear about this we
are all doomed !!!
Hi Peter :)
--
Ken Tyler - 1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> I was looking through Ken's links and ended up in this page:
> http://www.io.com/~wwagner/pov.html
>
> I would want to seriously warn about this #exec patch (specially
> because povray 3.5 might include it).
>
> Povray is currently quite safe to use. You can download a .pov file and
> render it with povray and the only harm it can do is to create an image
> file. It just can't do anything else. You can safely render a 10000 lines
> long pov file without having to worry about what does it contain.
>
The concern is of course not without cause. But the inclusion of file i/o
statement has already rendered this argument untrue. Yes, the #exec command
would facilitate writing malicious scripts, but the potential is already there.
Anyway, there are a thousand and one ways for the average Windows user to get
screwed (no, I mean figuratively speaing). Given all these options, is it really
likely that someone would specifically target the POV users?
I personally would like to have this functionality, since it is a very flexible
feature.
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 19 Oct 1999 11:54:39 -0700, Ken <tyl### [at] pacbellnet> wrote:
>If any of those infamous POV-Ray Bulgarian hackers hear about this we
>are all doomed !!!
>
>Hi Peter :)
Hi Ken :)
AFAIK I am the only Bulgarian who is using POV (after my friend
Stephan quit using it in favor of ASP programming yuck!). And you Ken
are the last person/AI to worry about. We've tried, God knows we've
tried, but the Ken secure grid is unbreakable (it were those darn
lasers that blew Ian's bum off the rail).
Sorry about OT... I WAS CHALLENGED! <grin®>
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote in message <380c362a@news.povray.org>...
> I was looking through Ken's links and ended up in this page:
>http://www.io.com/~wwagner/pov.html
>
> I would want to seriously warn about this #exec patch (specially
>because povray 3.5 might include it).
>
> Povray is currently quite safe to use. You can download a .pov file and
>render it with povray and the only harm it can do is to create an image
>file. It just can't do anything else. You can safely render a 10000 lines
>long pov file without having to worry about what does it contain.
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.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You are joking, right? 8^] I mean disk thrashing can be a way of life if
the file(s) parse a great deal or otherwise use extensive amounts of memory,
as many must know.
Bob
Mark Wagner <mar### [at] gtenet> wrote in message
news:380d52d2@news.povray.org...
>
> Nieminen Juha wrote in message <380c362a@news.povray.org>...
> > I was looking through Ken's links and ended up in this page:
> >http://www.io.com/~wwagner/pov.html
> >
> > I would want to seriously warn about this #exec patch (specially
> >because povray 3.5 might include it).
> >
> > Povray is currently quite safe to use. You can download a .pov file and
> >render it with povray and the only harm it can do is to create an image
> >file. It just can't do anything else. You can safely render a 10000 lines
> >long pov file without having to worry about what does it contain.
>
>
> 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.
>
> Mark
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And on Windows NT it's worse. I just got a new NT box placed in my office.
After booting into NT, and without even attempting to log-in, just booting, it
went crazy. After coming up with the NT log-in thingie, it then went into over
5-10 minutes of just constant disk thrashing. And that was with me not doing
anything.
omniVERSE wrote:
> You are joking, right? 8^] I mean disk thrashing can be a way of life if
> the file(s) parse a great deal or otherwise use extensive amounts of memory,
> as many must know.
>
> Bob
>
> Mark Wagner <mar### [at] gtenet> wrote in message
> news:380d52d2@news.povray.org...
> >
> >
> > 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.
> >
> > Mark
> >
> >
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> With #system/#exec it may be a good idea what I suggested earlier: you
> have to specify a command line switch to enable it.
>
A command line switch wouldn't do. Somebody already mentioned that you'd
probably put that in an inifile and forget about it. Prompting with every
POV-session would be better I think (as with the file-saving). I don't know if
this is as easy on all platforms.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
>
> The concern is of course not without cause. But the inclusion of file i/o
> statement has already rendered this argument untrue. Yes, the #exec command
> would facilitate writing malicious scripts, but the potential is already there.
> Anyway, there are a thousand and one ways for the average Windows user to get
> screwed (no, I mean figuratively speaing). Given all these options, is it really
> likely that someone would specifically target the POV users?
> I personally would like to have this functionality, since it is a very flexible
> feature.
>
> Margus
There are of course those outcasts that hate POV enough to target only that
group ;)
But seriously: it would be a great way to bypass all security measures because
there is no virus scanner yet that scans pov-scripts.
I hadn't thought of the possibility before, but Nieminen had a point here. As
with the macro-viruses: it sounds silly until it happens to you.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Remco de Korte <rem### [at] xs4allnl> wrote:
: A command line switch wouldn't do. Somebody already mentioned that you'd
: probably put that in an inifile and forget about it.
I mentioned it myself. Of course it's not perfect, but at least it's better
than nothing.
At least if you try to render a scene downloaded from a strange place,
you can check that it will not do any system calls nor file writings before
you render it.
: Prompting with every
: POV-session would be better I think (as with the file-saving). I don't know if
: this is as easy on all platforms.
It's very difficult to achieve this kind of prompting with ANSI C.
It also would be extremely tedious if you would need to answer to a
prompt every time you render your own scene.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Speaking about it... I have been thinking about a povray virus, but I
haven't yet figured out how to do it.
I mean a virus that will attach itself to all .pov-files it finds every time
an infected pov-file is rendered (of course it would be extremely easy
to detect and to disinfect; just watch the beginnin/end of the pov files and
remove the extra code from there, but that doesn't matter in this case because
the intention of the virus is not to make harm).
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?).
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 21 Oct 1999 00:41:48 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:
>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
I encountered a similar bug while I was trying to declare a string
defining a charset (all alphanumerals, punctuation and math symbols).
For some reason the parser choked on the double-quote and backslash,
even though I had a backslash before each of those. I did not explore
the depths of this bug because I used another approach.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal <sim### [at] studentmatnatuiono> wrote:
: for example via an "registered #exec
: programs" dialog from the menu
This can't be done with ANSI C.
: and *not* via an .INI-file.
Why not?
--
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 in message <380ed9d2@news.povray.org>...
>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.
OK, I'll post the virus in p.b.s-f
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha skrev i meldingen <380f4e3e@news.povray.org>...
>Simen Kvaal <sim### [at] studentmatnatuiono> wrote:
>: for example via an "registered #exec
>: programs" dialog from the menu
>
> This can't be done with ANSI C.
>
Why not? You can specify which .ini files to use, which, include direcroties
to use, why not specify which #exec commands to allow?
>: and *not* via an .INI-file.
>
> Why not?
Well, I thought maybe it was usual to supply an .ini file with the scene
file. If that ini-file included directives that let povray use a particular
#exec program, then we're back to the problem that the user has less
control. I think.
Simen.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal <sim### [at] studentmatnatuiono> wrote:
:>: for example via an "registered #exec
:>: programs" dialog from the menu
:>
:> This can't be done with ANSI C.
: Why not? You can specify which .ini files to use, which, include direcroties
: to use, why not specify which #exec commands to allow?
Well, you talked about a dialog in a menu...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If I understood correctly (after autoindenting with emacs :) ), it tries
all possible character combinations for a file name. That takes years!
There must be an easier way.
I was thinking about a codemax macro or similar: When active, each time
you save a .pov-file it will check if it's infected; it not, it infects it
and saves. The macro would be loaded when an infected file is rendered
(perhaps by writing to some codemax ini file first, or something).
But perhaps this is not possible.
--
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 in message <38105272@news.povray.org>...
> If I understood correctly (after autoindenting with emacs :) ), it tries
>all possible character combinations for a file name. That takes years!
My estimate is that it will take about 80 years on a resonably fast
computer.
> There must be an easier way.
I've come up with a few ideas, such as providing a method for ruling out
filenames that probably won't be used.
> I was thinking about a codemax macro or similar: When active, each time
>you save a .pov-file it will check if it's infected; it not, it infects it
>and saves. The macro would be loaded when an infected file is rendered
>(perhaps by writing to some codemax ini file first, or something).
> But perhaps this is not possible.
It might be possible. I'll have to check on that.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> If any of those infamous POV-Ray Bulgarian hackers hear about this we
> are all doomed !!!
No need to be Bulgarian! ;-) Right now, I'm writing the First
Ever POV-Ray-Virus [tm]!
Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> Seriously, folks, consider this:
>
> #fopen FILE "c:\\autoexec.bat" append
what's "autoexec.bat"?
SCNR
Markus
> The point is, if you don't trust the source of a file, don't run it. Getting
> an unknown POV script over the Internet is just as dangerous as getting C
> source code or Perl source code or source code in any other programming
> language, because that's what it is.
But POV-Ray is a _Renderer_, not a general purpose programming language.
Ok, it has a full-blown C-like syntax and all, but is this _really_
needed?
How about some restrictions on the available file I/O, such as allowing
only to read from and write to file in some kind of "sandbox", i.e.
_one_
special directory (and the sub dirs) that is assigned specifically for
that purpose. POV-Ray itself would then decide if it does it or not.
Markus
--
"Denkst Du vielleicht über den nächsten Satz nach, den Du sagen willst?
Ich nicht eine Sekunde!!!" H. Heinol in Val Thorens
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon A. Cruz" wrote:
>
> And on Windows NT it's worse. I just got a new NT box placed in my office.
> After booting into NT, and without even attempting to log-in, just booting, it
> went crazy. After coming up with the NT log-in thingie, it then went into over
> 5-10 minutes of just constant disk thrashing. And that was with me not doing
> anything.
Rip out that 16MB module and replace it by 256 MB. You'll be surprised.
Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 26 Oct 1999 15:03:19 +0200, Markus Becker wrote:
>Ron Parker wrote:
>> Seriously, folks, consider this:
>>
>> #fopen FILE "c:\\autoexec.bat" append
>
>what's "autoexec.bat"?
For that matter, what's "c:\\"?
Of course we could modify it to
#fopen FILE "~/.login" append
and have it write "cd ~\nrm -rf * >/dev/null\n" instead.
>How about some restrictions on the available file I/O, such as allowing
>only to read from and write to file in some kind of "sandbox", i.e.
>_one_
>special directory (and the sub dirs) that is assigned specifically for
>that purpose. POV-Ray itself would then decide if it does it or not.
That would solve one of the problems. The other problem that remains is
the shellout stuff, but those are relatively easy to check manually or
disable entirely.
Another way of looking at it is to not allow directory path separators
in filenames. Allow opens for read to find files anywhere an include
file would be found, and force opens for write to write to the directory
where the output file will be written. Of course, with the plethora of
different directory separators, this will be a daunting task, but I think
it's probably necessary.
Besides, we'll have to do something with the file i/o stuff to support
network rendering anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Tue, 26 Oct 1999 15:03:19 +0200, Markus Becker wrote:
> >Ron Parker wrote:
> >> Seriously, folks, consider this:
> >>
> >> #fopen FILE "c:\\autoexec.bat" append
> >
> >what's "autoexec.bat"?
>
> For that matter, what's "c:\\"?
>
> Of course we could modify it to
>
> #fopen FILE "~/.login" append
>
> and have it write "cd ~\nrm -rf * >/dev/null\n" instead.
>
I don't think a virus has to be cross-platform to do damage.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Another way of looking at it is to not allow directory path separators
: in filenames.
This would assume that directory separator is either "\" or "/".
It may be enough, but...
It might search for "povray.ini" in the currect directory and add some
nasty stuff there...
--
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 26 Oct 1999 10:06:09 -0400, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Another way of looking at it is to not allow directory path separators
>: in filenames.
>
> This would assume that directory separator is either "\" or "/".
Not necessarily. It would have to be done on an OS-by-OS basis.
For example, VMS uses square brackets around directory names,
and I think the Mac uses colons. Fortunately, config.h already
defines what a filename separator is for the OS in question.
> It might search for "povray.ini" in the currect directory and add some
>nasty stuff there...
True. Or some other ini file it can be sure is there - its own,
for example, in an attempt to bypass whatever visual auditing
someone might have done looking for shellouts. In that case, the
fix is to set an output directory that isn't in your INI path (but
is in your include path, because otherwise a lot of neat effects
wouldn't be possible.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker wrote:
> "Jon A. Cruz" wrote:
> >
> > And on Windows NT it's worse. I just got a new NT box placed in my office.
> > After booting into NT, and without even attempting to log-in, just booting, it
> > went crazy. After coming up with the NT log-in thingie, it then went into over
> > 5-10 minutes of just constant disk thrashing. And that was with me not doing
> > anything.
>
> Rip out that 16MB module and replace it by 256 MB. You'll be surprised.
>
> Markus
Strange. It does have 256 MB.
;-)
NT!! woo hoo!! Yeah!!!
NOT!
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > And on Windows NT it's worse. I just got a new NT box placed in my
office.
> > > After booting into NT, and without even attempting to log-in, just
booting, it
> > > went crazy. After coming up with the NT log-in thingie, it then went
into over
> > > 5-10 minutes of just constant disk thrashing. And that was with me not
doing
> > > anything.
quake 2 used to do this to my brother (about 30 secs after starting a dm),
ditched his poopy segate hd, and all is now well !
Rick
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon A. Cruz" wrote:
>
>
> Strange. It does have 256 MB.
> ;-)
>
> NT!! woo hoo!! Yeah!!!
>
> NOT!
>
Perhaps it was creating / updating the swap file. I have 256 megs
minimum of permanent swap on Win98, and when I restart after a crash, a
few minutes of disk thrashing is quaranteed (I have 128 megs of RAM)
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
