[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <9396dbd0a417440abe9bbb830e7b612f@kaspersky.com>
Date: Mon, 10 Dec 2018 12:48:43 +0000
From: Pavel Cheremushkin <Pavel.Cheremushkin@...persky.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: libvnc and tightvnc vulnerabilities
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/>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
