Package: tigervnc / 1.7.0+dfsg-7+deb9u1

Metadata

Package Version Patches format
tigervnc 1.7.0+dfsg-7+deb9u1 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
0102 fix spelling error in manpages to shutup lintian.patch | (download)

unix/x0vncserver/x0vncserver.man | 4 2 + 2 - 0 !
vncviewer/vncviewer.man | 2 1 + 1 - 0 !
2 files changed, 3 insertions(+), 3 deletions(-)

---
0151 make cmake enable options mandatory if turned on.patch | (download)

CMakeLists.txt | 31 24 + 7 - 0 !
1 file changed, 24 insertions(+), 7 deletions(-)

---
0904 Added RH patch tigervnc11 rh588342.patch which fixes.patch | (download)

unix/xserver/hw/vnc/Input.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 [patch 4/7] added rh patch tigervnc11-rh588342.patch which fixes eq overflowing bug.

Xvnc could become unresponsive and the following error message was shown
in the log: "[mi] EQ overflowing. The server is probably stuck in an
infinite loop.". This was caused by a large number of user input events
in the Xvnc event queue, which were being processed too slowly. With
this update, this issue no longer occurs and the system works as
expected. (BZ#588342)

0905 Added RH patch tigervnc11 rh690245.patch which add T.patch | (download)

common/rfb/SecurityClient.cxx | 2 1 + 1 - 0 !
common/rfb/SecurityServer.cxx | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 [patch 5/7] added rh patch tigervnc11-rh690245.patch which add tls encryption to vencrypt

TigerVNC (Xvnc, x0vncserver, the libvnc.so module, and vncviewer) now
supports TLS encryption (using VeNCrypt) which allows TLS encrypted
communication between a server and a viewer. (BZ#653491)

find fltk libs.diff | (download)

CMakeLists.txt | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

---
fix linking.diff | (download)

CMakeLists.txt | 6 6 + 0 - 0 !
unix/vncconfig/CMakeLists.txt | 2 1 + 1 - 0 !
vncviewer/CMakeLists.txt | 2 1 + 1 - 0 !
3 files changed, 8 insertions(+), 2 deletions(-)

---
f/tigervnc11 gethomedir.patch | (download)

unix/xserver/hw/vnc/Makefile.am | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

---
f/tigervnc shebang.patch | (download)

unix/vncserver | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
f/tigervnc cursor.patch | (download)

vncviewer/Viewport.cxx | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
fix build error with xserver 1.19.patch | (download)

unix/xserver/hw/vnc/xorg-version.h | 4 3 + 1 - 0 !
unix/xserver117.patch | 53 0 + 53 - 0 !
2 files changed, 3 insertions(+), 54 deletions(-)

 fix build error with xorg xserver 1.19.
 Ideas were taken from
 https://lists.x.org/archives/xorg-devel/2016-October/051495.html
v2 Add xorg xserver 1.19 support to tigervnc.patch | (download)

unix/xserver/hw/vnc/XserverDesktop.cc | 183 183 + 0 - 0 !
unix/xserver/hw/vnc/XserverDesktop.h | 7 7 + 0 - 0 !
unix/xserver/hw/vnc/vncBlockHandler.c | 19 19 + 0 - 0 !
unix/xserver/hw/vnc/vncExtInit.cc | 13 13 + 0 - 0 !
unix/xserver/hw/vnc/vncExtInit.h | 5 5 + 0 - 0 !
unix/xserver/hw/vnc/vncHooks.c | 21 18 + 3 - 0 !
6 files changed, 245 insertions(+), 3 deletions(-)

---
fix xorg1.19 inetd mode.patch | (download)

unix/xserver/hw/vnc/xvnc.c | 10 9 + 1 - 0 !
1 file changed, 9 insertions(+), 1 deletion(-)

 [patch] fix -inetd not working with xserver >= 1.19

xserver 1.19's OsInit will create a pollfd, followed by checking if fd 2 /
stderr is writable and if it is not, replacing fd 2 with /dev/null.

Since we close stderr in inetd mode to avoid xserver messages being send
to the client as vnc data, the pollfd becomes fd 2, only to be replaced
by /dev/null since a pollfd is not writable.

This commit fixes this by opening /dev/null directly after the close(2),
avoiding that the pollfd becomes fd 2.

Alan Coopersmith: Change to use dup2() for atomic switch of fd

Signed-off-by: Hans de Goede <hdegoede@redhat.com>

fix xorg1.19 server side cursor.patch | (download)

unix/xserver/hw/vnc/XserverDesktop.cc | 9 9 + 0 - 0 !
1 file changed, 9 insertions(+)

 [patch] fix server side cursor support for xorg server >= 1.19

This is a minimal backport of the fix applied by Pierre Ossman on 2016-10-05 in
the commit b192107b302098864358cd54b6323129c23e271e on TigerVNC master while
unifying some code paths for Xorg server < 1.19 and >= 1.19.

The function XserverDesktop::readWakeupHandler is used by the code path for
Xorg server < 1.19. Here, the mouse movement is propagated from the VNC client
to the server via the following code snippet:

  // We are responsible for propagating mouse movement between clients
  int cursorX, cursorY;
  vncGetPointerPos(&cursorX, &cursorY);
  if (oldCursorPos.x != cursorX || oldCursorPos.y != cursorY) {
    oldCursorPos.x = cursorX;
    oldCursorPos.y = cursorY;
    server->setCursorPos(oldCursorPos);
  }

The corresponding function XserverDesktop::blockHandler, which is used by
the Xorg server >= 1.19 code path, was missing this. Hence, this patches adds
the missing cursor propagation code.

CVE 2014 8240 849479.patch | (download)

unix/x0vncserver/Image.cxx | 19 19 + 0 - 0 !
vncviewer/X11PixelBuffer.cxx | 19 19 + 0 - 0 !
2 files changed, 38 insertions(+)

---
CVE 2014 8241 849478.patch | (download)

common/Xregion/Region.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

---
Fix buffer overflow in ModifiablePixelBuffer fillRec.patch | (download)

common/rfb/PixelBuffer.cxx | 19 15 + 4 - 0 !
1 file changed, 15 insertions(+), 4 deletions(-)

 [patch] fix buffer overflow in modifiablepixelbuffer::fillrect.

It can be triggered by RRE message with subrectangle out of framebuffer
boundaries. It may prevent the same kind of issue caused by evil message
from another encoding too.

CVE 2017 7393 Prevent double free by crafted fences.patch | (download)

common/rfb/SMsgWriter.cxx | 4 3 + 1 - 0 !
common/rfb/VNCSConnectionST.cxx | 1 1 + 0 - 0 !
2 files changed, 4 insertions(+), 1 deletion(-)

 [patch] prevent double free by crafted fences.

If client sent fence with some data, followed by fence with no data (length 0), the original fence data were freed, but the pointer kept pointing at them. Sending one more fence would attempt to free them again.

CVE 2017 7395 Fix crash from integer overflow in SMsgReader readCl.patch | (download)

common/rfb/SMsgReader.cxx | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 [patch 1/2] fix crash from integer overflow in
 SMsgReader::readClientCutText

The length sent by client is U32, but is converted into int. If it was bigger than 0x7fffffff the resulting int is negative, it passes the check against maxCutText and later throws std::bad_alloc from CharArray which takes down the whole server.

All the Streaming API deals with lengths in ints, so we can't tell it to skip that big amount of data. And it is not realistic to expect more than 2GB of clipboard data anyway. So lets just throw rdr::Exception that will disconnect this client and keep the server alive.

CVE 2017 7396 Prevent leak of SecurityServer and ClientServer.patch | (download)

common/rfb/CConnection.cxx | 5 2 + 3 - 0 !
common/rfb/CConnection.h | 4 2 + 2 - 0 !
common/rfb/SConnection.cxx | 12 5 + 7 - 0 !
common/rfb/SConnection.h | 2 1 + 1 - 0 !
4 files changed, 10 insertions(+), 13 deletions(-)

 [patch 2/2] prevent leak of securityserver and clientserver.

They are created in SConnection's and CConnection's constructors but never destroyed.

There is no reason for the indirection, so lets make them direct members.

CVE 2017 7392 Delete underlying ssecurity in SSecurityVeNCrypt.patch | (download)

common/rfb/SSecurityVeNCrypt.cxx | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 [patch] delete underlying ssecurity in ssecurityvencrypt.

Otherwise it gets leaked which would allow even not authenticated clients to exhaust server memory.

CVE 2017 7394 0001 Fix checkNoWait logic in SSecurityPlain.patch | (download)

common/rfb/SSecurityPlain.cxx | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch 1/2] fix checknowait logic in ssecurityplain.

Currently it proceeds only if there aren't enough data in queue and then it blocks waiting.
Also the required amount to receive from network is (ulen + plen), not (ulen + plen + 2).

This allowed not authenticated clients to deny service to everyone.

CVE 2017 7394 0002 Limit max username password size in SSecurityPlain.patch | (download)

common/rfb/SSecurityPlain.cxx | 7 7 + 0 - 0 !
common/rfb/SSecurityPlain.h | 3 3 + 0 - 0 !
2 files changed, 10 insertions(+)

 [patch 2/2] limit max username/password size in ssecurityplain.

Setting the limit to 1024 which should be still more than enough.

Unlimited ulen and plen can cause various security problems:
  * Overflow in `is->checkNoWait(ulen + plen)` causing it to contine when there is not enough data and then wait forever.
  * Overflow in `new char[plen + 1]` that would allocate zero sized array which succeeds but returns pointer that should not be written into.
  * Allocation failure in `new char[plen + 1]` from trying to allocate too much and crashing the whole server.

All those issues can be triggered by a client before authentication.

CVE 2019 15691.patch | (download)

common/rdr/ZlibInStream.cxx | 13 7 + 6 - 0 !
common/rdr/ZlibInStream.h | 2 1 + 1 - 0 !
common/rfb/TightDecoder.cxx | 3 2 + 1 - 0 !
common/rfb/zrleDecode.h | 3 2 + 1 - 0 !
4 files changed, 12 insertions(+), 9 deletions(-)

 [patch] make zlibinstream more robust against failures

Move the checks around to avoid missing cases where we might access
memory that is no longer valid. Also avoid touching the underlying
stream implicitly (e.g. via the destructor) as it might also no
longer be valid.

A malicious server could theoretically use this for remote code
execution in the client.

Issue found by Pavel Cheremushkin from Kaspersky Lab

CVE 2019 15692.patch | (download)

common/rfb/Cursor.cxx | 3 1 + 2 - 0 !
common/rfb/EncodeManager.cxx | 5 1 + 4 - 0 !
common/rfb/PixelBuffer.cxx | 74 58 + 16 - 0 !
common/rfb/PixelBuffer.h | 11 9 + 2 - 0 !
unix/x0vncserver/XPixelBuffer.cxx | 7 2 + 5 - 0 !
unix/xserver/hw/vnc/XserverDesktop.cc | 26 11 + 15 - 0 !
unix/xserver/hw/vnc/XserverDesktop.h | 2 1 + 1 - 0 !
7 files changed, 83 insertions(+), 45 deletions(-)

 [patch] restrict pixelbuffer dimensions to safe values

We do a lot of calculations based on pixel coordinates and we need
to make sure they do not overflow. Restrict the maximum dimensions
we support rather than try to switch over all calculations to use
64 bit integers.

This prevents attackers from injecting code by specifying a
huge framebuffer size and relying on the values overflowing to
access invalid areas of the heap.

This primarily affects the client which gets both the screen
dimensions and the pixel contents from the remote side. But the
server might also be affected as a client can adjust the screen
dimensions, as can applications inside the session.

Issue found by Pavel Cheremushkin from Kaspersky Lab.

CVE 2019 15693.patch | (download)

common/rfb/tightDecode.h | 37 21 + 16 - 0 !
1 file changed, 21 insertions(+), 16 deletions(-)

 [patch] handle empty tight gradient rects

We always assumed there would be one pixel per row so a rect with
a zero width would result in us writing to unknown memory.

This could theoretically be used by a malicious server to inject
code in to the viewer process.

Issue found by Pavel Cheremushkin from Kaspersky Lab.