Stable ChunkVNC Repeater - Perl Script

[Rat]

Yeah I hear you Chunk... Karl's a very sharp dude!

[B]

Great news!

I reflected the change in my "All VNC Repeaters" post at [topic=27489][/topic]

I would love there to be "one repeater to rule them all". This is all fun, but confusing!


Edit: Oh, also, Rat, could you please explain a bit more about Karl's security concerns with using the CGI version, and how they could best be addressed? A big selling point of the Perl repeater was that it could be used with shared hosting accounts (as you helped us understand). If it's trivial to subvert (even with a web interface on top) then perhaps it's not a good idea to do it at all that way.... Also, tiny typo -- you have it as 16-April but today is the 6th.

[Rat]

Oh, also, Rat, could you please explain a bit more about Karl's security concerns with using the CGI version, and how they could best be addressed

Well Karl's chief concern was that a malicious user may specify a log file or pid file name which might overwrite some other file, (unlikely to happen in a properly configured environment). He suggested hard-coding the log file and pid file names into the script if you didn't require this feature. (I use it because I am running multiple repeaters.) He has also added some validation of the CGI arguments to ensure they are properly formed.

My (professional) opinion is that this is not a significant security risk.

Notes:
1. Having a "CGI interface" simply means that the script can be executed using a web browser and entering the appropriate URL.

2. The CGI interface can be turned off by simply commenting out the call to "check_cgi()".

3. Set the permissions for the "ultravnc_repater.pl" script to "0700" to prevent web access, (This is what I do).

4. If you were planning to make the script directly publicly accessible then I would password protect it.

5. The main reason the CGI interface is there is to help facilitate users constructing their own web interface for the script, (as several have indicated they would like to do).


Late Breaking News! I've released a new version of the script that addresses all of these concerns, effectively eliminating them as issues.

1. Added a "validateEnv()" function to ensure that only valid argument values may be passed to the script.

2. Chained the Log and PID files to reside in the same folder as the script. (This pretty much removes most of the security issues mentioned by Karl, although users could still conceivably overwrite existing files in that particular folder.)

[B]

Very nice, thanks Rat!

So obscuring the names of the log and PID files would close up even that last hole?

[Rat]

> So obscuring the names of the log and PID files would close up even that last hole?

I don't think so. After all regardless of how you pass the file names to the script those files will still be overwritten. I could modify the filename validation regular expression to limit valid file names to ".log" and ".pid".

[B]

Well instead of hard-coding a single name as Karl suggested, you could restrict the beginning of the file names too I suppose, just auto-generating sequentially numbered files. Then the worst that could happen is filling up the directory with files.

?

[Rat]

File name extension protection added
As well as being chained to the same folder as the script, Log and PID files are now forced to have only ".log" and ".pid" file extensions and invalid extensions will be replaced with valid ones.

As always the script may be downloaded from here: http://www.vuware.com/chunkvnc/ultravnc_repeater.zip

[KyferEz]

Rat,

I'm trying to figure all this out, and like to fully understand what I'm doing before embarking upon a task. That said, I could use some guidance setting this up in a shared hosting environment.

So what do I do? Is it as simple as uploading the script to the cgi bin of my web server and verifying the perl path? If so, what then? Do I, in step 2 of this: http://www.chunkvnc.com/installationguide.html simply use the url to the perl script as the WAN address? If so, then what do I use as the LAN address? Do I figure out my shared server's IP?

So once done, I can upload the chunkvnc's generated instandsupport.exe to my web server, a client click on it and run it and I can see that client as a possible connection?

Thanks!

[KyferEz]

No one can help me understand this? I am not well-versed in Linux, but I really want to set it up to run on my webserver, which is a shared Linux server...

[supercoe]

Sorry I can't help much here as I've yet to try this script on a shared host.

I've been really happy with my 2host Linux VPS and Karls Perl Repeater for my test bed.

Repeaters can be run in many different environments, Windows is the easiest to setup which is why it's recommended in the installation guide.

simply use the url to the perl script as the WAN address?
No

[KyferEz]

My problem with windows is that means using my office connection with the typical limited upload bandwidth. I don't want sudden lags due to someone doing a large transfer at the office.

VPS certainly would work, except that I'm lacking in Linux expertise, therefore, I'm leery of putting out money for one when I'm not sure I could utilize it for my needs.

For a quickie test-bed I could use my office connection, but for long term I really want it on the server so I can eventually develop a web interface to manage the connections (like logmein has).

[Rat]

No one can help me understand this? I am not well-versed in Linux, but I really want to set it up to run on my webserver, which is a shared Linux server...

Sorry KyferEz, didn't see your post there.

To run the perl repeater script in a shared hosting environment just upload it to the /public_html/cgi-bin folder, set the file permissions to 700 and then telnet/SSH2 to your web server and run the script like this:

/home/[YOUR USER NAME]/public_html/cgi-bin/ultravnc_repeater.pl -L BG -r -C -c 5901 -s 5501

Notes:
1. Your directory paths may differ from the above examples, but these should be correct for 90% of standard linux shared hosting environments.
2. If you can't Telnet/SSH2 to your web server, (you should be able to) then the script can also be invoked as a URL. This will require setting up some password protection on the folder and setting the permissions appropriately. Let me know if this is neccessary.

Cheers,
Rat.

[Rat]

More Notes:
1. You can check if the script is running by issuing the following command:

netstat -anp --tcp | grep perl

2. Your ChunkVNC repeater address will be the web page address of your shared hosting account.

[KyferEz]

Ah, thanks so much! I'll give that a try today.

[KyferEz]

Well it worked, but didn't work. I was able to run the script, but hostgator.com refuses to allow incoming traffic on any ports for shared accounts.
Now what? VPS account and I'm gonna have to try and learn linux console I guess... Gonna need some help too.

Everything is either difficult and time-consuming or expensive. There doesn't seem to be a middle ground. Sigh

[B]

Ky, they have to allow traffic on SOME ports; otherwise they're not hosting much of anything! Please see my other response to you, and check out http://forum.ultravnc.info/viewtopic.php?t=27489 for a link to specifying directory paths in a repeater address.

[Rat]

Well it worked, but didn't work. I was able to run the script, but hostgator.com refuses to allow incoming traffic on any ports for shared accounts.
Now what? VPS account and I'm gonna have to try and learn linux console I guess... Gonna need some help too.

Everything is either difficult and time-consuming or expensive. There doesn't seem to be a middle ground. Sigh

Well without trying to look too much like I'm making a gratuitous plug for my own company...
I would be happy to provide web hosting that allows for the VNC repeater script.
Just let me know what your hosting requirements are here: www.vuhosting.com.

Cheers,
Rat.

[supercoe]

Well without trying to look too much like I'm making a gratuitous plug for my own company...

With all the work you do around here I'm sure it's ok you plug your company when there is a user in need.

Where are your servers located?

[Rat]

Thanks Chunk...

We have servers in the US and Australia. I would also have to specify which ports the user is to use for their VNC repeater... (since I have other clients also running repeaters on the same server)

[B]

So it's not trivial to use with any ordinary script-enabled shared hosting account after all? That's too bad.

Then it sounds as if you need an accommodating host like Rat's VUHosting, or a VPS (and in the latter case you don't really need the CGI method)?

[supercoe]

I guess I just don't see big deal with setting it up in Linux?
Maybe I should write up a guide but I simply purchased a cheap Linux VPS, used wget to download Karls repeater and ran it with perl.

[Rat]

So it's not trivial to use with any ordinary script-enabled shared hosting account after all? That's too bad.

Then it sounds as if you need an accommodating host like Rat's VUHosting, or a VPS (and in the latter case you don't really need the CGI method)?

I just tested it on a completely unrelated shared hosting environment and it ran fine... make sure the file permissions are set correctly, (700) and the script is in the cgi-bin folder.

[B]

So in that 3rd party hoster you didn't need them to forward any ports? What ports and syntax did you use to connect to the repeater? Was port 80 sufficient?

[duck]

Wed May 4 08:16:26 2011: new vnc server connecting.
Wed May 4 08:16:26 2011: ultravnc_repeater: short read 12 != 250
Wed May 4 08:38:58 2011: new vnc server connecting.
Wed May 4 08:38:58 2011: ultravnc_repeater: short read 12 != 250
Wed May 4 09:01:40 2011: new vnc server connecting.
Wed May 4 09:01:40 2011: ultravnc_repeater: short read 12 != 250
Wed May 4 09:24:32 2011: new vnc server connecting.
Wed May 4 09:24:32 2011: ultravnc_repeater: short read 12 != 250

How do I solve this above issue. I have a customer that has launched chunkVNC and given me the access code but the repeater perl script never fully reads the server. Internally I get

Wed May 4 08:04:33 2011: new vnc server connecting.
Wed May 4 08:04:33 2011: storing new vnc server with ID:119526.

and some customer are able to connect properly just no all. What am I doing wrong or can you point me in the correct direction to solve this issue.

Thank you
Duck

[Rat]

So in that 3rd party hoster you didn't need them to forward any ports? What ports and syntax did you use to connect to the repeater? Was port 80 sufficient?

No port forwarding required and I called it with the following command:

Code: Select all

/home/user_name/public_html/cgi-bin/ultravnc_repeater.pl -L BG -r -C -c 5901 -s 5501 -l test -p test

This tells it to...
(a) fork into the background, (i.e. run as a daemon),
(b) refuse new server/client connections when there is an existing server/client ID,
(c) have the script periodically check for and close initial connections that have gone away before the partner connects,
(d) listen on port 5901 for the VNC client and port 5501 for the server,
(e) log to "test.log" and store the master PID in "test.pid".

[Rat]

Wed May 4 08:16:26 2011: new vnc server connecting.
Wed May 4 08:16:26 2011: ultravnc_repeater: short read 12 != 250
Wed May 4 08:38:58 2011: new vnc server connecting.
Wed May 4 08:38:58 2011: ultravnc_repeater: short read 12 != 250
Wed May 4 09:01:40 2011: new vnc server connecting.
Wed May 4 09:01:40 2011: ultravnc_repeater: short read 12 != 250
Wed May 4 09:24:32 2011: new vnc server connecting.
Wed May 4 09:24:32 2011: ultravnc_repeater: short read 12 != 250

How do I solve this above issue. I have a customer that has launched chunkVNC and given me the access code but the repeater perl script never fully reads the server. Internally I get

Wed May 4 08:04:33 2011: new vnc server connecting.
Wed May 4 08:04:33 2011: storing new vnc server with ID:119526.

and some customer are able to connect properly just no all. What am I doing wrong or can you point me in the correct direction to solve this issue.

To be honest I have no idea what's happening here, (sorry). The "short read" error means that it didn't fill the read buffer from the socket. Looking at the script code, I'm not sure why Karl interprets this as an error, (I will ask him). You could try modifying that part of the code as follows and see how it goes:

Code: Select all

  if ($got_alarm) {lprint("$prog: read timed out: $!");}
  elsif (! defined $n) {lprint("$prog: read error: $!");}
//  elsif ($repeater_bufsize > 0 && $n != $size) {lprint("$prog: short read $n != $size $!"); close $sock;}
  elsif (($client_listen && $fh == $client_listen) || ($client_listen6 && $fh == $client_listen6)) {do_new_client($sock, $buf);}
  elsif (($server_listen && $fh == $server_listen) || ($server_listen6 && $fh == $server_listen6)) {do_new_server($sock, $buf);}

I can't guarantee that this won't break something, (Karl always does stuff for a good reason, even if I don't know what it is ).

Also as Chunk will attest to, there are firewall and network configurations that will block the repeater and ChunkVNC from working... he could provide more and better details than I.

Finally, I occasionally have connections drop out, usually re-running the viewer fixes it.

[B]

So in that 3rd party hoster you didn't need them to forward any ports? What ports and syntax did you use to connect to the repeater? Was port 80 sufficient?

No port forwarding required and I called it with the following command:

Code: Select all

/home/[b][i]user_name[/i][/b]/public_html/cgi-bin/ultravnc_repeater.pl -L BG -r -C -c 5901 -s 5501 -l test -p test

This tells it to...
(a) fork into the background, (i.e. run as a daemon),
(b) refuse new server/client connections when there is an existing server/client ID,
(c) have the script periodically check for and close initial connections that have gone away before the partner connects,
(d) listen on port 5901 for the VNC client and port 5501 for the server,
(e) log to "test.log" and store the master PID in "test.pid".

But what syntax did the client and server use to connect? Wouldn't your 3rd party shared hoster need to forward ports if all the remotely connecting viewer specified were repeaterhostname::port ?

I'm just trying to grok the whole picture. Apparently with hostgator, at least, they need to forward ports and refused to.

[Rat]

But what syntax did the client and server use to connect? Wouldn't your 3rd party shared hoster need to forward ports if all the remotely connecting viewer specified were repeaterhostname::port ?

I'm just trying to grok the whole picture. Apparently with hostgator, at least, they need to forward ports and refused to.

The Perl repater script is a general repeater, it basically listens on the two ports specified and faithfully echo's traffic from each to the other. (The only exception to this rule is if you omit the "-R" switch which causes the "RFB 000.000" string to be sent to the client during the connection initialisation. This is required for VNC.) Although I haven't tried it, I suspect the repeater script could function as a general proxy service, (which is potentially also extremely useful).

Since it listens and sends on the two specified ports, the host must allow traffic to be sent and received at the server on these ports. Its important to note however that the connection does not originate from the repeater but rather from the external VNC client and server. This should reduce the likelihood of a firewall/reverse proxy blocking the traffic.


BTW: That code snippet I posted earlier of the perl script's command-line call had some BBCode buried in it. It should have been as below: (where "user_name" is replaced with your actual account username)

Code: Select all

/home/user_name/public_html/cgi-bin/ultravnc_repeater.pl -L BG -r -C -c 5901 -s 5501 -l test -p test

[B]

Huh? I appreciate your answer, Rat, but it doesn't seem to address my question?

That is, yes the repeater is listening on two ports, and yes the endpoints initiate connections, but on a shared repeater host those ports may have to be forwarded by the hosting company, just as with your own company hosting, right?

In your latest test with a 3rd party hoster, I am asking if (and why or why not) any manual port forwarding was involved.

Simply, if you and I are on HostCo.com, and myserver.hostco.com and yourserver.hostco.com resolve to the same IP address, won't HostCo have to forward specific ports for each of us, and wouldn't that prevent both of us from using the same repeater ports for our own repeaters?

Or am I missing something?

[Rat]

Simply, if you and I are on HostCo.com, and myserver.hostco.com and yourserver.hostco.com resolve to the same IP address, won't HostCo have to forward specific ports for each of us

Short Answer is: "It depends." Since the traffic doesn't originate from the hostco.com server then no port forwarding is required, however the ports would need to be allowed for outgoing connections, (I would expect this to be the case for most providers).

...wouldn't that prevent both of us from using the same repeater ports for our own repeaters?

I would also have to specify which ports the user is to use for their VNC repeater... (since I have other clients also running repeaters on the same server)