libvnc and tightvnc vulnerabilities

[Pavel Cheremushkin <Pavel.Cheremushkin () kaspersky com>]

Hello,

LibVNC is a cross-platform library to implement programs that use RFB (remote frame buffer protocol). Although, on its 
Github page (https://github.com/LibVNC/libvncserver) it is stated that libvnc is designed to implement server-side 
software, it also has functionality to implement a VNC client. Due to the fact that many ICS vendors use open source 
VNC products I would like to drag some attention to the VNC products because they have some problems that should be 
fixed asap.

During recent research of libvnc I managed to discover few vulnerabilities (11 in total) which affect products that are 
using libvncserver and libvncclient 
(https://github.com/LibVNC/libvncserver/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Apaulcher). There are a couple of 
issues left to the next release of libvnc (https://github.com/LibVNC/libvncserver/milestone/4), but the packages, that 
I have recently reviewed still didn't patch vulnerabilities that were found quite some time ago. Meanwhile, an issue 
that has been found by @ateska (https://github.com/LibVNC/libvncserver/issues/211) is critical, affects VirtualBox and 
probably every multithreading VNC server that is based on libvnc and it is still not patched after almost a year.

At first, I thought that these issues were inside the code that was written by libvnc developers, by this wasn't 
exactly the case. Some of them (i.e. buffer overflow inside heap structure in CoRRE handler 
https://github.com/LibVNC/libvncserver/issues/250) were inside vulnerable code written by AT&T Laboratories in 1999 and 
got copy-pasted by many software developers (you can see it by trying to find HandleCoRREBPP function in Github 
search), as well by LibVNC and TightVNC  developers. LibVNC contributors managed to fix all security issues that I have 
reported to them so far. Also I tried to report these vulnerabilities in TightVNC software version 1.3.10 (which is 
used, for example, in latest Ubuntu "xtightvncviewer" package) to GlavSoft company, who are authors of the TightVNC 
software:

```
1. global buffer overflow in corre.c
    In `vnc_unixsrc/vncviewer/corre.c` inside the `HandleCoRREBPP` function global buffer overflow occurs due to the 
lack of size check.
    `buffer` is defined in rfbproto.c:96 as ```char buffer[640*480];```. Inside `HandleCoRREBPP` function data is being 
read to the buffer `ReadFromRFBServer(buffer, hdr.nSubrects * (4 + (BPP / 8))` where `hdr.nSubrects` is 32-bit unsigned 
integer controlled by remote user.

2. heap buffer overflow in rfbServerCutText handler
    Heap buffer overflow in `rfbServerCutText` handler inside `HandleRFBServerMessage` happens due to the malloc 
argument unsigned integer overflow on line rfbproto.c:1220. Suppose msg.sct.length equals 0xffffffff, then 
`malloc(msg.sct.length+1);` = `malloc(0);` will allocate small heap chunk of size 0x10. But `msg.sct.length` = 
0xffffffff bytes may be read in this chunk on line 1222 (`ReadFromRFBServer(serverCutText, msg.sct.length)`).

3. heap buffer overflow in InitialiseRFBConnection function
    Heap buffer overflow `InitialiseRFBConnection` function happens due to the malloc argument unsigned integer 
overflow on line rfbproto.c:307. Because of the integer overflow `malloc` function will allocate small heap chunk of 
size 0x10 and 0xffffffff bytes will be read into the chunk by ReadFromRFBServer function.

4. null-ptr dereference in `zlib.c`
    Because malloc result is not checked after allocation on line zlib.c:56 null pointer dereference is possible if 
malloc argument is too big and malloc fill fail to allocate memory Allocation of raw buffer : `raw_buffer = (char*) 
malloc( raw_buffer_size );`, next usage of raw_buffer is on line 68
```

But GlavSoft representative politely declined to patch the 1.X version of TightVNC software, because it doesn't bring 
any income to the company. They are currently developing TightVNC 2.X, which is not affected by GPL licenses in 
third-party code. This is the exact answer of the GlavSoft representative (in Russian):



К сожалению, как коммерческой организации, нам совершенно нерентабельно заниматься TightVNC 1.x, т.к. оно содержит 
чужой GPL-код и поэтому мы не имеем возможность предлагать этот код под другими лицензиями. А техподдержка в случае с 
TightVNC никогда не приносила нам сколь-нибудь существенного дохода. Поэтому, увы, версии 1.x нам совсем неинтересны.

That being said, package maintainers should probably patch these vulnerabilities by themselves if they want to continue 
supporting TightVNC 1.X packages in their repositories.

These bugs are so obvious and I still cannot believe that they haven't been already found by anyone else. So please 
tell me if these issues have been already discovered before, but remained unpatched for some reason.


Best Regards,
Pavel Cheremushkin
Security Researcher| ICS CERT Vulnerability Research Group | Kaspersky Lab
39A bld.2 Leningradskoye Highway, Moscow 125212, Russia | 
www.kaspersky.com<http://www.kaspersky.com/>,www.securelist.com<http://www.securelist.com/>