World: r3wp

and? You are imo reading rebol executable, that is all :-)

he's trying to start it up and leave a console running

No, the second time i do a wait. that should be slower.

ah, but the console would have to get that command (wait 4) - do 
you think it is passed to it?

I think so.

but hard to exploit more. security is on, so only access to cgi-bin 
and childs. cgi-bin should not be writable by the cgi-user. except 
if cgis run as your account, then i could write a script with -cs 
and call that in the next step.

and getting data out does not work, because rebol first prints its 
version-stuff, and webserver thinks "header wrong"

ok, just tried it - Volker is right ...

I can see processes, for one read/custom two of them - dunno why 
...

but you could flood server, running hundreds of instances .... keeping 
them in memory for long time ...

now - is it a rebol vulnerability? Or just putting rebol into cgi-bin 
is the simple cause?

Yes, but i could also call hundreds of regular scripts to keep server 
busy. although this way is  easier, i can allocate lots of mem with 
one call.

I would say: do no exe in cgi if it cant handle cgi. and rebol cant 
(except with script).

but it could protect itself by checking for cgi without -c? So not 
a bug, but a missing feature?

do no exe in cgi -> put no exe in cgi-bin

security through obsfuscation .. rename your rebol binary !

how could it protect itself? How does it know it is in place to be 
run as a cgi interpreter?

Hmm, good question. May be hard.

Graham - my server is far from popular. I think no-one will do Volker's 
like trick. But you might be right, if we teach ppl to simply put 
rebol into cgi-bin dir, and then such "vulnerability" is found, ISPs 
might hate it ....

renaming executable might work ... sufficiently enough imo ...

I see no reason why not to put it somewhere else, outside of web-folders.

Hosts wont' normally put rebol into their own cgi-bin

Graham - because then user can't do it, ISP has to  ...

Volker, often hosts will not allow exes outside cgi-bin

Usually you can put it in homedir or such.

so, even if you put outside the webfolders, you can't then execute 
it

Volker: but usually you don't get console access, only ftp to copy 
your web to ...

Hmm, that is bad. thought exes outside would be ok. talk to host?

I did that for micha and it worked. thought that is common.

advantage of having rebol in cgi-bin is, that you can update it yourself, 
not asking your ISP to update it for you each time new version is 
out :-)

can you have subdirs with cgi-scripts? so that you can call http://cgi-bin/project1/script.cgi
?

then maybe you can restrict access to that folder by .htaccess.

well, as for my server, I can install rebol regullarly. We just were 
thinking loud here with Graham, if that is good aproach or not to 
have it in cgi-bin, so simply you could run your rebol scripts without 
ISP to even know you are using rebol :-)

Grahams obfuscation-trick should work too, as long as nobody on the 
same server tries to break in.

I would ask isp to allow exes in another folder. dont know how he 
would react thought.

btw, ct mentioned virtual server for e4.99. Dont know about quality, 
and i see german, do you see english? http://www.netfabrik.de/

cgi - maybe an extra exe which only runs as cgi?

REBOL does not have to be in the cgi-bin folder.

If it is elsewhere, have a shebang in the first line of each script 
to point to where the exexcutable is.
(apologies if I'm missing the point of the discussion here)

Seems some hosts disable exes outside of cgi-bin

That would be a problem :-)

my host does that .. I'm only allowed exes in the cgi-local directory

Did you test subdir?

and since my cgi-local is a mapped directory, I can't create subdirectories

Sad. and no linux-sdk?

ah! you should be able to trap things in %user.r .

if you can write there.

This is an odd one.  I have a form that records a user's email address, 
the time they filled in the form, and their ip address.

A user did so, and got two subscription notices - timed 30 seconds 
or so apart.  So, both were his email address, but the ip address 
of the later one was from Google!

My deduction is that somehow google is tracking his movements, and 
submitted the form themselves to get the content ...

I guess I should download the web logs to see what actually happened.

Yep, that was it.  Mediapartners-Google/2.1 submitted the form again. 
 It looks like if you have the Google search bar, it submits all 
your internet traffic to google, who then go and try and index that 
site - including submitting your email address to a form!!