As of now, only LibVNCServer makes uses of these digest functions _and_
they depend on sys/uio.h, but in the future LibVNCClient will need those
as well.
These functions can be used to send already compressed jpegs to a
client, circumventing the usual rect/region update methods which
operate on a raw rgb framebuffer. Rename the functions with the usual
rfb prefix and add the prototypes in rfb.h.
Signed-off-by: Eddie James <eajames@us.ibm.com>
This patch constrains a client cut text length to 1 MB. Otherwise
a client could make server allocate 2 GB of memory and that seems to
be to much to classify it as a denial of service.
The limit also prevents from an integer overflow followed by copying
an uninitilized memory when processing msg.cct.length value larger
than SIZE_MAX or INT_MAX - sz_rfbClientCutTextMsg.
This patch also corrects accepting length value of zero (malloc(0) is
interpreted on differnet systems differently).
CVE-2018-7225
<https://github.com/LibVNC/libvncserver/issues/218>
add wstestdata.c, because the python data generation script has too many
dependencies
remove some redundance from jpeg test creation
add support for decoding close messages
modify automake to include ws_decode test
add python frame generator for decode tests
modify configure to only include ws_decode test if preconditions are
fulfilled
fix critical heap-based buffer overflow which allowed easy modification
of a return address via an overwritten function pointer
fix bug causing connections to fail due a "one websocket frame = one
ws_read" assumption, which failed with LibVNCServer-0.9.11
refactor websocket Hybi decode to use a simple state machine for
decoding of websocket frames
Since autotools officially is no longer supported (see various github
issues), drop the related infrastructure to stop tempting people to use
it for building.
Signed-off-by: Bert van Hall <bert.vanhall@gmx.de>
Discovered by madscientist159 on 11 Jan 2015:
"noted in testing with the threaded server build, whereby
if newClientHook() returned RFB_CLIENT_ON_HOLD there was no
way to release the hold when the server became ready"
Make it possible to get autoPort behavior with either ipv4 or ipv6
disabled, by setting rfbScreen->ipv6port or rfbScreen->port to a
negative number. This will make it possible for x11vnc to enforce
its -noipv6 option, as discussed in the following bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672449
Avoid calling SSL_pending when connection is already closed, calling SSL_pending with connection already closed is crashing.
To reproduce, open a secure websocket binay protocol connection with libvncserver compiled with OpenSSL, and when libvncserver is waiting for rfbProcessClientProtocolVersion send any invalid char, it will fail and call rfbCloseClient whith destroy all SSL context, calling SSL_pending after that will generate a invalid access.