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>
- As with the encoder, the decoder now uses the TurboJPEG wrapper, which
allows it to decode JPEG images directly into the framebuffer. This
eliminates a buffer copy (CopyRectangle()) as well as the expensive
RGB pixel conversion in DecompressJpegRectBPP(). The TurboJPEG
wrapper performs RGB pixel conversion more optimally, and only when
necessary (it uses the libjpeg-turbo colorspace extensions when
available, in order to avoid RGB conversion.)
- The other Tight subencoding types are also now decoded directly into
the framebuffer, which eliminates buffer copies.
- The Tight decoder now supports the rfbTightNoZlib extension, which
allows the server to bypass zlib compression when Compression Level 0
is selected. The encoder already supports this extension. Passing
the data stream through zlib when Compression Level 0 is selected
needlessly wastes CPU time, since all zlib is doing is copying the
data internally into its own structures.
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
This update makes the example work on versions of ffmpeg newer than "ancient," fixes a bunch of bugs in the process, and with better documentation of the pitfalls.
It turns out some server implementations (namely VMware ESXi 6.5) expect
1 as the only non-zero value for the SetPixelFormat message whereas the protocol
states every non-zero value is valid
(https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#setpixelformat).
Anyway, setting this to 1 shouldn't hurt.
Fixes #141