novnc/websockify-other

Assorted ports of websockify code to other languages

websockify-other's Issues

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?

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

The server can handle how many concurrent clients?

I mean c

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

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].

websockify C binary mode?

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

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 &

can we achive ws only instead of wss

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

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.

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.

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

binary support in C version Websockify

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

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.