novnc/websockify-other

Assorted ports of websockify code to other languages

noVNC: HTML VNC Client Library and Application

Description

noVNC is both a HTML VNC client JavaScript library and an application built on top of that library. noVNC runs well in any modern browser including mobile browsers (iOS and Android).

Many companies, projects and products have integrated noVNC including OpenStack, OpenNebula, LibVNCServer, and ThinLinc. See the Projects and Companies wiki page for a more complete list with additional info and links.

Table of Contents

• News/help/contact
• Features
• Screenshots
• Browser Requirements
• Server Requirements
• Quick Start
• Installation from Snap Package
• Integration and Deployment
• Authors/Contributors

News/help/contact

The project website is found at novnc.com.

If you are a noVNC developer/integrator/user (or want to be) please join the noVNC discussion group.

Bugs and feature requests can be submitted via github issues. If you have questions about using noVNC then please first use the discussion group. We also have a wiki with lots of helpful information.

If you are looking for a place to start contributing to noVNC, a good place to start would be the issues that are marked as "patchwelcome". Please check our contribution guide though.

If you want to show appreciation for noVNC you could donate to a great non- profits such as: Compassion International, SIL, Habitat for Humanity, Electronic Frontier Foundation, Against Malaria Foundation, Nothing But Nets, etc.

Features

• Supports all modern browsers including mobile (iOS, Android)
• Supported authentication methods: none, classical VNC, RealVNC's RSA-AES, Tight, VeNCrypt Plain, XVP, Apple's Diffie-Hellman, UltraVNC's MSLogonII
• Supported VNC encodings: raw, copyrect, rre, hextile, tight, tightPNG, ZRLE, JPEG
• Supports scaling, clipping and resizing the desktop
• Local cursor rendering
• Clipboard copy/paste with full Unicode support
• Translations
• Touch gestures for emulating common mouse actions
• Licensed mainly under the MPL 2.0, see the license document for details

Screenshots

Running in Firefox before and after connecting:

 

See more screenshots here.

Browser Requirements

noVNC uses many modern web technologies so a formal requirement list is not available. However these are the minimum versions we are currently aware of:

• Chrome 64, Firefox 79, Safari 13.4, Opera 51, Edge 79

Server Requirements

noVNC follows the standard VNC protocol, but unlike other VNC clients it does require WebSockets support. Many servers include support (e.g. x11vnc/libvncserver, QEMU, and MobileVNC), but for the others you need to use a WebSockets to TCP socket proxy. noVNC has a sister project websockify that provides a simple such proxy.

Quick Start

• Use the novnc_proxy script to automatically download and start websockify, which includes a mini-webserver and the WebSockets proxy. The --vnc option is used to specify the location of a running VNC server:

  ./utils/novnc_proxy --vnc localhost:5901

• If you don't need to expose the web server to public internet, you can bind to localhost:

  ./utils/novnc_proxy --vnc localhost:5901 --listen localhost:6081

• Point your browser to the cut-and-paste URL that is output by the novnc_proxy script. Hit the Connect button, enter a password if the VNC server has one configured, and enjoy!

Installation from Snap Package

Running the command below will install the latest release of noVNC from Snap:

sudo snap install novnc

Running noVNC from Snap Directly

You can run the Snap-package installed novnc directly with, for example:

novnc --listen 6081 --vnc localhost:5901 # /snap/bin/novnc if /snap/bin is not in your PATH

If you want to use certificate files, due to standard Snap confinement restrictions you need to have them in the /home/<user>/snap/novnc/current/ directory. If your username is jsmith an example command would be:

novnc --listen 8443 --cert ~jsmith/snap/novnc/current/self.crt --key ~jsmith/snap/novnc/current/self.key --vnc ubuntu.example.com:5901

Running noVNC from Snap as a Service (Daemon)

The Snap package also has the capability to run a 'novnc' service which can be configured to listen on multiple ports connecting to multiple VNC servers (effectively a service runing multiple instances of novnc). Instructions (with example values):

List current services (out-of-box this will be blank):

sudo snap get novnc services
Key             Value
services.n6080  {...}
services.n6081  {...}

Create a new service that listens on port 6082 and connects to the VNC server running on port 5902 on localhost:

sudo snap set novnc services.n6082.listen=6082 services.n6082.vnc=localhost:5902

(Any services you define with 'snap set' will be automatically started) Note that the name of the service, 'n6082' in this example, can be anything as long as it doesn't start with a number or contain spaces/special characters.

View the configuration of the service just created:

sudo snap get novnc services.n6082
Key                    Value
services.n6082.listen  6082
services.n6082.vnc     localhost:5902

Disable a service (note that because of a limitation in Snap it's currently not possible to unset config variables, setting them to blank values is the way to disable a service):

sudo snap set novnc services.n6082.listen='' services.n6082.vnc=''

(Any services you set to blank with 'snap set' like this will be automatically stopped)

Verify that the service is disabled (blank values):

sudo snap get novnc services.n6082
Key                    Value
services.n6082.listen  
services.n6082.vnc

Integration and Deployment

Please see our other documents for how to integrate noVNC in your own software, or deploying the noVNC application in production environments:

• Embedding - For the noVNC application
• Library - For the noVNC JavaScript library

Authors/Contributors

See AUTHORS for a (full-ish) list of authors. If you're not on that list and you think you should be, feel free to send a PR to fix that.

• Core team:

  • Samuel Mannehed (Cendio)
  • Pierre Ossman (Cendio)

• Previous core contributors:

  • Joel Martin (Project founder)
  • Solly Ross (Red Hat / OpenStack)

• Notable contributions:

  • UI and Icons : Pierre Ossman, Chris Gordon
  • Original Logo : Michael Sersen
  • tight encoding : Michael Tinglof (Mercuri.ca)
  • RealVNC RSA AES authentication : USTC Vlab Team

• Included libraries:

  • base64 : Martijn Pieters (Digital Creations 2), Samuel Sieb (sieb.net)
  • DES : Dave Zimmerman (Widget Workshop), Jef Poskanzer (ACME Labs)
  • Pako : Vitaly Puzrin (https://github.com/nodeca/pako)

Do you want to be on this list? Check out our contribution guide and start hacking!

websockify-other's Issues

Glitches using websockify-c

I used websockify c as a testbed, but there were a couple glitches.

SSL seems to be unsupported but there's some code that tries to link to it.

There are several chuncks of code that expect the payload of messages to be
encoded with base64, but that doesn't seem to be a thing. I nuked the thoughts
of base64.

There might have been a few other tweaks. If anyone is paying attention to this, I"ll work with you
to provide a satisfactory pull request.

Feature request: Simple web server support in C version.

Hi. I noticed that C version websockify is missing simple web server feature. Can you please add it? I tried to do that, but it was a very ugly solution.

The server can handle how many concurrent clients?

I mean c

can we achive ws only instead of wss

websockify C binary mode?

The C version of websockify doesn't support the binary mode? Could it be easy add?

b64_ntop() / b64_pton() not universally available on all C libraries

I am trying to cross-compile the C version of websockify for an embedded system that uses uclibc instead of glibc.
However it seems b64_ntop() / b64_pton() is not available with that.

websocket.o: In function `encode_hixie':
websocket.c:(.text+0x3f0): undefined reference to `b64_ntop'
websocket.o: In function `decode_hixie':
websocket.c:(.text+0x4e8): undefined reference to `b64_pton'
websocket.o: In function `encode_hybi':
websocket.c:(.text+0x614): undefined reference to `b64_ntop'
websocket.o: In function `decode_hybi':
websocket.c:(.text+0x86c): undefined reference to `b64_pton'
websocket.o: In function `do_handshake':
websocket.c:(.text+0x1224): undefined reference to `b64_ntop'
collect2: error: ld returned 1 exit status

Please consider bundling those methods locally with websockify.

websockify stucks at select timeout

Hi,
I am using websockify to transfer Encoded Video Streams (H.264) captured from RTSP server to a player integrated in WeB-UI.
The behavior observed is randomly websockify stops passing the stream as it gets stuck in "select timeout" in *void do_proxy(ws_ctx_t ws_ctx, int target) in websockify.c
The socket connection state remains in ESTABLISHED mode though no packets are forwarded from websockify.
The arguments passed to execute websockify are: /customer/websockify --cert /customer/libs/lighttpd/ssl/server.crt --key /customer/libs/lighttpd/ssl/server.key 9500 192.168.1.250:554 &

binary support in C version Websockify

Seems C version did not support array buffer yet, right?

Security: Stack based Buffer Overflows

WebSockify Bug Report - Project Srishti

Note: This is an old bug found by source code audit.

While looking at websockify.c in websockify/other, I noticed an obvious Stack based Buffer Overflow bug.

Let's first see how settings_t structure has been defined:

typedef struct {
    int verbose;
    char listen_host[256];
    int listen_port;
    void (*handler)(ws_ctx_t*);
    int handler_id;
    char *cert;
    char *key;
    int ssl_only;
    int daemon;
    int run_once;
} settings_t;

We can see that size of listen_host is 256 bytes as sizeof(char) is 1 byte. I found two occurrence of the Stack based Buffer Overflow afterwards I did not audit further as I was asked to stop the audit.

Now, let's see the occurrence where the Overflow occurs.

found = strstr(argv[optind], ":");
if (found) {
    memcpy(settings.listen_host, argv[optind], found - argv[optind]);
    settings.listen_port = strtol(found + 1, NULL, 10);
} else {
    settings.listen_host[0] = '\0';
    settings.listen_port = strtol(argv[optind], NULL, 10);
}
optind++;
if (settings.listen_port == 0) {
    usage("Could not parse listen_port\n");
}

found = strstr(argv[optind], ":");
if (found) {
    memcpy(target_host, argv[optind], found - argv[optind]);
    target_port = strtol(found + 1, NULL, 10);
} else {
    usage("Target argument must be host:port\n");
}
if (target_port == 0) {
    usage("Could not parse target port\n");
}

Let's understand the below given piece of code.

found = strstr(argv[optind], ":");
if (found) {
    memcpy(settings.listen_host, argv[optind], found - argv[optind]);
    settings.listen_port = strtol(found + 1, NULL, 10);
}

We know that strstr() returns the pointer to the found substring. According to this piece of code, when : is found in a string, found variable holds the pointer to the start of the substring.

Developer has ignored the fact that, found - argv[optind] will vary depending the how long the argument is provided. Hence, overflows the listen_host[256] buffer.

This allows us to take control of the Instruction Pointer when void (*handler)(ws_ctx_t*) is overflowed in the same structure and ws_ctx handler is called.

As a proof of concept, I have developed a dummy program that show Stack base Buffer Overflow happening.

websockifyboftest.c

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
    char *found;
    char listen_host[12];

    found = strstr(argv[1], ":");
    
    printf("argv[1]: %p\n", argv[1]);
    printf("found: %p\n", found);
    printf("The substring is: %s\n", found);
    printf("found-argv[1]: %d\n", found-argv[1]);
    
    if (found) {
        printf("Storing: listen_host");
        memcpy(listen_host, argv[1], found-argv[1]);
    }
    
    printf("listen_host: %s\n", listen_host);

    return(0);
}

Output

ashfaq@hacksys:~$ ./websockifyboftest AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:A

argv[1]: 0x7ffd199af357
found: 0x7ffd199af387
The substring is: :A
found-argv[1]: 48
Storing: listen_hostlisten_host: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)

Recommendation

The size of copy should be exactly same as the size of the buffer available.

memcpy(settings.listen_host, argv[optind], sizeof(settings.listen_host));

Credits

Ashfaq Ansari - Project Srishti

websockify.rb with SSL

I was wondering how to use websockify.rb with SSL.

Other implementations seem to require a path to the SSL certificate, however in websockify.rb there's no indication for this requirement, eventhough a comment in the file states WSS is supported?

When I try to use noVNC with the encrypt option enabled, I see this:
"Uncaught exception: undefined method []' for nil:NilClass 1: Trace: ./websocket.rb:363:indo_handshake'"

Would it be a good idea to use em-websocket [https://github.com/igrigorik/em-websocket] with noVNC?

The C version doesn't close its file descriptors

Once the total number of processed connections passes the file descriptor limit (On my Gentoo box, it's 1024) then the program just starts spamming ERROR on accept: Too many open files

Here's the output in my terminal http://puu.sh/2Imf6.png

Use of Uninitialized Variable

WebSockify Bug Report - Project Srishti

Note: This is an old bug found by source code audit.

While looking at websockify.c in websockify/other, I noticed an obvious Use of Uninitialized Variable bug.

unsigned int tout_start, tout_end, cout_start, cout_end;
unsigned int tin_start, tin_end;
ssize_t len, bytes;

tout_start = tout_end = cout_start = cout_end;

You can see that tout_start, tout_end, cout_start, cout_end variables are not initialized before they are used. However, after evaluating the control flow, I do not see a security issue.

if (tout_end == tout_start) {
    // Nothing queued for target, so read from client
    FD_SET(client, &rlist);
} else {
    // Data queued for target, so write to it
    FD_SET(target, &wlist);
}
if (cout_end == cout_start) {
    // Nothing queued for client, so read from target
    FD_SET(target, &rlist);
} else {
    // Data queued for client, so write to it
    FD_SET(client, &wlist);
}

But, this is not recommended in Secure Coding practices.

The issue can be depicted by below given dummy C snippet.

dummy.c

#include <stdio.h>

int main()
{
    unsigned int tout_start, tout_end, cout_start, cout_end;
    
    tout_start = tout_end = cout_start = cout_end;
    
    printf("&tout_start: [%p], tout_start: [%p]\n", &tout_start, tout_start);
    printf("&tout_end: [%p], tout_end: [%p]\n", &tout_end, tout_end);
    printf("&cout_start: [%p], cout_start: [%p]\n", &cout_start, cout_start);
    printf("&cout_end: [%p], cout_end: [%p]\n", &cout_end, cout_end);

    return 0;
}

Output

sh-4.3$ main
&tout_start: [0x7ffd2384337c], tout_start: [0x23843460]
&tout_end: [0x7ffd23843378], tout_end: [0x23843460]
&cout_start: [0x7ffd23843374], cout_start: [0x23843460]
&cout_end: [0x7ffd23843370], cout_end: [0x23843460]

sh-4.3$ main
&tout_start: [0x7ffd8cb6c63c], tout_start: [0x8cb6c720]
&tout_end: [0x7ffd8cb6c638], tout_end: [0x8cb6c720]
&cout_start: [0x7ffd8cb6c634], cout_start: [0x8cb6c720]
&cout_end: [0x7ffd8cb6c630], cout_end: [0x8cb6c720]

From the output, you can observe that the value of tout_start, tout_end, cout_start, cout_end variables differ each run.

Recommendation

Initialize the variables with a concrete value.

tout_start = tout_end = cout_start = cout_end = 0;

Credits

Ashfaq Ansari - Project Srishti

Websockify-c: Sec-WebSocket-Origin is mandatory not following RFC3864

Hi,

In the C parser the "Sec-WebSocket-Origin: " seems mandatory whereas the RFC3864 says:

The request MUST include a header with the name "Sec-WebSocket-Origin" if the request is coming from a browser client. If the connection is from a non-browser client, the request MAY include this header if the semantics of that client match the use-case described here for browser clients. The value of this header MUST be the ASCII serialization of origin of the context in which the code establishing the connection is running, and MUST be lower-case. The value MUST NOT contain letters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) [I-D.ietf-websec-origin].

Memory leak

Observing memory leak when running for a longtime

Large message support in C (> 65535 bytes)

Thanks for the fantastic product, first of all!

My project requires that I sometimes send somewhat large messages (base64 encoded text) broken into chunks (normally 8192 bytes at a time).

I noticed when trying to utilize the C version of the websockify server that it seems to choke when I attempt to send several large messages in a row. I tested 8192 byte chunks down to 2048 byte chunks and got a base64 exception every time. The debugging output was:
0: Base64 decode error code -1 0: decoding error
*** glibc detected *** ./websockify: free(): invalid next size (normal): 0x09826948 ***

I did NOT encounter this problem in the Python version, however.

In case it makes a difference, I'm NOT using the websockify.js library in this instance, so I'm just calling the native WebSocket.send() method to send the data.

We would prefer to use the C version if this particular issue can be resolved. Any thoughts?

Thanks!

• John