[debian-lts] libvncserver package
Hi all,
I would like to send debdiff of libvncserver package for reviewing.
Could any one please review it and give me some comments.
Thanks and best regards
Cong
--
=====================================================================
Nguyen The Cong (Mr)
Software Engineer
Toshiba Software Development (Vietnam) Co.,Ltd
519 Kim Ma street, Ba Dinh District, Hanoi, Vietnam
tel: +84-4-2220 8801 (Ext. 208)
e-mail: cong.nguyenthe@toshiba-tsdv.com
=====================================================================
Note: This e-mail message may contain personal information or confidential information. If you are not the addressee of this message, please delete this message and kindly notify the sender as soon as possible - do not copy, use, or disclose this message.
diff -u libvncserver-0.9.7/debian/changelog libvncserver-0.9.7/debian/changelog
--- libvncserver-0.9.7/debian/changelog
+++ libvncserver-0.9.7/debian/changelog
@@ -1,3 +1,11 @@
+libvncserver (0.9.7-2+deb6u1) squeeze-lts; urgency=low
+
+ * Non-maintainer upload.
+ * Fix several security issues as in CVE-2014-6051, CVE-2014-6052
+ CVE-2014-6053, CVE-2014-6054 and CVE-2014-6055
+
+ -- Nguyen Cong <cong.nguyenthe@toshiba-tsdv.com> Fri, 16 Jan 2015 08:50:52 +0700
+
libvncserver (0.9.7-2) unstable; urgency=low
* QA upload.
diff -u libvncserver-0.9.7/debian/patches/series libvncserver-0.9.7/debian/patches/series
--- libvncserver-0.9.7/debian/patches/series
+++ libvncserver-0.9.7/debian/patches/series
@@ -4,0 +5,5 @@
+05_CVE_2014_6051.patch
+06_CVE_2014_6052.patch
+07_CVE_2014_6053.patch
+08_CVE_2014_6054.patch
+09_CVE_2014_6055.patch
only in patch2:
unchanged:
--- libvncserver-0.9.7.orig/debian/patches/08_CVE_2014_6054.patch
+++ libvncserver-0.9.7/debian/patches/08_CVE_2014_6054.patch
@@ -0,0 +1,90 @@
+Description: Do not accept a scaling factor of zero as in CVE-2014-6054
+ Do not accept a scaling factor of zero on
+ PalmVNCSetScaleFactor and SetScale client->server messages. This would cause
+ a division by zero and crash the server.
+Origin: Upstream
+Bug-Debian: https://bugs.debian.org/762745
+Applied-Upstream: Refer to these upstream commits:
+ https://github.com/newsoft/libvncserver/commit/05a9bd41a8ec0a9d580a8f420f41718bdd235446
+ https://github.com/newsoft/libvncserver/commit/f18f24ce65f5cac22ddcf3ed51417e477f9bad09 (hardening)
+ https://github.com/newsoft/libvncserver/commit/5dee1cbcd83920370a487c4fd2718aa4d3eba548 (required for sparc)
+ https://github.com/newsoft/libvncserver/commit/819481c5e2003cd36d002336c248de8c75de362e (hardening)
+ https://github.com/newsoft/libvncserver/commit/e5d9b6a07257c12bf3b6242ddea79ea1c95353a8 (hardening)
+Last-Update: 2015-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libvncserver/rfbserver.c
++++ b/libvncserver/rfbserver.c
+@@ -2348,6 +2348,13 @@ rfbProcessClientNormalMessage(rfbClientP
+ rfbCloseClient(cl);
+ return;
+ }
++
++ if (msg.ssc.scale == 0) {
++ rfbLogPerror("rfbProcessClientNormalMessage: will not accept a scale factor of zero");
++ rfbCloseClient(cl);
++ return;
++ }
++
+ rfbStatRecordMessageRcvd(cl, msg.type, sz_rfbSetScaleMsg, sz_rfbSetScaleMsg);
+ rfbLog("rfbSetScale(%d)\n", msg.ssc.scale);
+ rfbScalingSetup(cl,cl->screen->width/msg.ssc.scale, cl->screen->height/msg.ssc.scale);
+@@ -2364,6 +2371,13 @@ rfbProcessClientNormalMessage(rfbClientP
+ rfbCloseClient(cl);
+ return;
+ }
++
++ if (msg.ssc.scale == 0) {
++ rfbLogPerror("rfbProcessClientNormalMessage: will not accept a scale factor of zero");
++ rfbCloseClient(cl);
++ return;
++ }
++
+ rfbStatRecordMessageRcvd(cl, msg.type, sz_rfbSetScaleMsg, sz_rfbSetScaleMsg);
+ rfbLog("rfbSetScale(%d)\n", msg.ssc.scale);
+ rfbScalingSetup(cl,cl->screen->width/msg.ssc.scale, cl->screen->height/msg.ssc.scale);
+--- a/libvncserver/scale.c
++++ b/libvncserver/scale.c
+@@ -70,6 +70,11 @@
+ (double) ((int) (x)) : (double) ((int) (x) + 1) )
+ #define FLOOR(x) ( (double) ((int) (x)) )
+
++static inline int pad4(int value) {
++ int remainder = value & 3;
++ return value + (remainder == 0 ? 0 : 4 - remainder);
++}
++
+
+ int ScaleX(rfbScreenInfoPtr from, rfbScreenInfoPtr to, int x)
+ {
+@@ -285,14 +290,29 @@ rfbScreenInfoPtr rfbScaledScreenAllocate
+ ptr = malloc(sizeof(rfbScreenInfo));
+ if (ptr!=NULL)
+ {
++ int allocSize;
++
+ /* copy *everything* (we don't use most of it, but just in case) */
+ memcpy(ptr, cl->screen, sizeof(rfbScreenInfo));
++
++ /* SECURITY: make sure that no integer overflow will occur afterwards.
++ * Note: this is defensive coding, as the check should have already been
++ * performed during initial, non-scaled screen setup.
++ */
++ allocSize = pad4(width * (ptr->bitsPerPixel/8)); /* per protocol, width<2**16 and bpp<256 */
++ if ((height == 0) || (allocSize >= (SIZE_MAX / height)))
++ {
++ free(ptr);
++ return NULL; /* malloc() will allocate an incorrect buffer size - early abort */
++ }
++
++ /* Resume copy everything */
+ ptr->width = width;
+ ptr->height = height;
+ ptr->paddedWidthInBytes = (ptr->bitsPerPixel/8)*ptr->width;
+
+ /* Need to by multiples of 4 for Sparc systems */
+- ptr->paddedWidthInBytes += (ptr->paddedWidthInBytes % 4);
++ ptr->paddedWidthInBytes = pad4(ptr->paddedWidthInBytes);
+
+ /* Reset the reference count to 0! */
+ ptr->scaledScreenRefCount = 0;
only in patch2:
unchanged:
--- libvncserver-0.9.7.orig/debian/patches/06_CVE_2014_6052.patch
+++ libvncserver-0.9.7/debian/patches/06_CVE_2014_6052.patch
@@ -0,0 +1,54 @@
+Description: Check for MallocFrameBuffer() return value as in CVE-2014-6052
+ 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.
+Origin: Upstream
+Bug-Debian: https://bugs.debian.org/762745
+Applied-Upstream: https://github.com/newsoft/libvncserver/commit/85a778c0e45e87e35ee7199f1f25020648e8b812
+Last-Update: 2015-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libvncclient/rfbproto.c
++++ b/libvncclient/rfbproto.c
+@@ -1163,7 +1163,8 @@ HandleRFBServerMessage(rfbClient* client
+ if (rect.encoding == rfbEncodingNewFBSize) {
+ client->width = rect.r.w;
+ client->height = rect.r.h;
+- client->MallocFrameBuffer(client);
++ if (!client->MallocFrameBuffer(client))
++ return FALSE;
+ SendFramebufferUpdateRequest(client, 0, 0, rect.r.w, rect.r.h, FALSE);
+ rfbClientLog("Got new framebuffer size: %dx%d\n", rect.r.w, rect.r.h);
+ continue;
+@@ -1592,7 +1593,8 @@ HandleRFBServerMessage(rfbClient* client
+ return FALSE;
+ client->width = rfbClientSwap16IfLE(msg.rsfb.framebufferWidth);
+ client->height = rfbClientSwap16IfLE(msg.rsfb.framebufferHeigth);
+- client->MallocFrameBuffer(client);
++ if (!client->MallocFrameBuffer(client))
++ return FALSE;
+ SendFramebufferUpdateRequest(client, 0, 0, client->width, client->height, FALSE);
+ rfbClientLog("Got new framebuffer size: %dx%d\n", client->width, client->height);
+ break;
+@@ -1605,7 +1607,8 @@ HandleRFBServerMessage(rfbClient* client
+ return FALSE;
+ client->width = rfbClientSwap16IfLE(msg.prsfb.buffer_w);
+ client->height = rfbClientSwap16IfLE(msg.prsfb.buffer_h);
+- client->MallocFrameBuffer(client);
++ if (!client->MallocFrameBuffer(client))
++ return FALSE;
+ SendFramebufferUpdateRequest(client, 0, 0, client->width, client->height, FALSE);
+ rfbClientLog("Got new framebuffer size: %dx%d\n", client->width, client->height);
+ break;
+--- a/libvncclient/vncviewer.c
++++ b/libvncclient/vncviewer.c
+@@ -220,7 +220,8 @@ static rfbBool rfbInitConnection(rfbClie
+
+ client->width=client->si.framebufferWidth;
+ client->height=client->si.framebufferHeight;
+- client->MallocFrameBuffer(client);
++ if (!client->MallocFrameBuffer(client))
++ return FALSE;
+
+ if (client->updateRect.x < 0) {
+ client->updateRect.x = client->updateRect.y = 0;
only in patch2:
unchanged:
--- libvncserver-0.9.7.orig/debian/patches/09_CVE_2014_6055.patch
+++ libvncserver-0.9.7/debian/patches/09_CVE_2014_6055.patch
@@ -0,0 +1,132 @@
+Description: Fix multiple stack-based buffer overflows in file transfer feature as in CVE-2014-6055
+ Note: The patch has been modified to be a targeting fix without the risk of breaking
+ ABI -- https://bugzilla.redhat.com/show_bug.cgi?id=1144293#c2.
+ However, as this function is not in header it is unlikely to be used outside of the lib.
+Origin: Upstream
+Bug-Debian: https://bugs.debian.org/762745
+Applied-Upstream: Refer to these commits:
+ https://github.com/newsoft/libvncserver/commit/06ccdf016154fde8eccb5355613ba04c59127b2e
+ https://github.com/newsoft/libvncserver/commit/f528072216dec01cee7ca35d94e171a3b909e677
+ https://github.com/newsoft/libvncserver/commit/256964b884c980038cd8b2f0d180fbb295b1c748
+Last-Update: 2015-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libvncserver/rfbserver.c
++++ b/libvncserver/rfbserver.c
+@@ -1155,21 +1155,36 @@ typedef struct {
+ #define RFB_FILE_ATTRIBUTE_TEMPORARY 0x100
+ #define RFB_FILE_ATTRIBUTE_COMPRESSED 0x800
+
+-rfbBool rfbFilenameTranslate2UNIX(rfbClientPtr cl, char *path, char *unixPath)
++rfbBool rfbFilenameTranslate2UNIX(rfbClientPtr cl, /* in */ char *path, /* out */ char *unixPath )
+ {
+ int x;
+ char *home=NULL;
+
++ size_t unixPathMaxLen = MAX_PATH;
+ FILEXFER_ALLOWED_OR_CLOSE_AND_RETURN("", cl, FALSE);
+
++ /*
++ * Do not use strncpy() - truncating the file name would probably have undesirable side effects
++ * Instead check if destination buffer is big enough
++ */
++
++ if (strlen(path) >= unixPathMaxLen)
++ return FALSE;
++
+ /* C: */
+ if (path[0]=='C' && path[1]==':')
++ {
+ strcpy(unixPath, &path[2]);
++ }
+ else
+ {
+ home = getenv("HOME");
+ if (home!=NULL)
+ {
++ /* Re-check buffer size */
++ if ((strlen(path) + strlen(home) + 1) >= unixPathMaxLen)
++ return FALSE;
++
+ strcpy(unixPath, home);
+ strcat(unixPath,"/");
+ strcat(unixPath, path);
+@@ -1207,7 +1222,8 @@ rfbBool rfbSendDirContent(rfbClientPtr c
+ FILEXFER_ALLOWED_OR_CLOSE_AND_RETURN("", cl, FALSE);
+
+ /* Client thinks we are Winblows */
+- rfbFilenameTranslate2UNIX(cl, buffer, path);
++ if (!rfbFilenameTranslate2UNIX(cl, buffer, path))
++ return FALSE;
+
+ if (DB) rfbLog("rfbProcessFileTransfer() rfbDirContentRequest: rfbRDirContent: \"%s\"->\"%s\"\n",buffer, path);
+
+@@ -1474,7 +1490,9 @@ rfbBool rfbProcessFileTransfer(rfbClient
+ /* add some space to the end of the buffer as we will be adding a timespec to it */
+ if ((buffer = rfbProcessFileTransferReadBuffer(cl, length))==NULL) return FALSE;
+ /* The client requests a File */
+- rfbFilenameTranslate2UNIX(cl, buffer, filename1);
++ if (!rfbFilenameTranslate2UNIX(cl, buffer, filename1))
++ goto fail;
++
+ cl->fileTransfer.fd=open(filename1, O_RDONLY, 0744);
+
+ /*
+@@ -1565,16 +1583,17 @@ rfbBool rfbProcessFileTransfer(rfbClient
+ */
+ if ((buffer = rfbProcessFileTransferReadBuffer(cl, length))==NULL) return FALSE;
+
+- /* Parse the FileTime */
+- p = strrchr(buffer, ',');
++ /* Parse the FileTime
++ * TODO: FileTime is actually never used afterwards
++ */
++ p = strrchr(buffer, ',');
+ if (p!=NULL) {
+ *p = '\0';
+- strcpy(szFileTime, p+1);
++ strncpy(szFileTime, p+1, sizeof(szFileTime));
++ szFileTime[sizeof(szFileTime)-1] = '\x00'; /* ensure NULL terminating byte is present, even if copy overflowed */
+ } else
+ szFileTime[0]=0;
+
+-
+-
+ /* Need to read in sizeHtmp */
+ if ((n = rfbReadExact(cl, (char *)&sizeHtmp, 4)) <= 0) {
+ if (n != 0)
+@@ -1586,7 +1605,8 @@ rfbBool rfbProcessFileTransfer(rfbClient
+ }
+ sizeHtmp = Swap32IfLE(sizeHtmp);
+
+- rfbFilenameTranslate2UNIX(cl, buffer, filename1);
++ if (!rfbFilenameTranslate2UNIX(cl, buffer, filename1))
++ goto fail;
+
+ /* If the file exists... We can send a rfbFileChecksums back to the client before we send an rfbFileAcceptHeader */
+ /* TODO: Delta Transfer */
+@@ -1739,8 +1759,12 @@ rfbBool rfbProcessFileTransfer(rfbClient
+ {
+ /* Split into 2 filenames ('*' is a seperator) */
+ *p = '\0';
+- rfbFilenameTranslate2UNIX(cl, buffer, filename1);
+- rfbFilenameTranslate2UNIX(cl, p+1, filename2);
++ if (!rfbFilenameTranslate2UNIX(cl, buffer, filename1))
++ goto fail;
++
++ if (!rfbFilenameTranslate2UNIX(cl, p+1, filename2))
++ goto fail;
++
+ retval = rename(filename1,filename2);
+ if (DB) rfbLog("rfbProcessFileTransfer() rfbCommand: rfbCFileRename(\"%s\"->\"%s\" -->> \"%s\"->\"%s\") %s\n", buffer, filename1, p+1, filename2, (retval==-1?"Failed":"Success"));
+ /*
+@@ -1760,6 +1784,9 @@ rfbBool rfbProcessFileTransfer(rfbClient
+ /* NOTE: don't forget to free(buffer) if you return early! */
+ if (buffer!=NULL) free(buffer);
+ return TRUE;
++fail:
++ if (buffer!=NULL) free(buffer);
++ return FALSE;
+ }
+
+ /*
only in patch2:
unchanged:
--- libvncserver-0.9.7.orig/debian/patches/05_CVE_2014_6051.patch
+++ libvncserver-0.9.7/debian/patches/05_CVE_2014_6051.patch
@@ -0,0 +1,39 @@
+Description: Fix integer overflow in MallocFrameBuffer() as in CVE-2014-6501
+ Promote integers to uint64_t to avoid integer overflow issue during
+ frame buffer allocation for very large screen sizes
+Origin: Upstream
+Bug-Debian: https://bugs.debian.org/762745
+Applied-Upstream: https://github.com/newsoft/libvncserver/commit/045a044e8ae79db9244593fbce154cdf6e843273
+Last-Update: 2015-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libvncclient/vncviewer.c
++++ b/libvncclient/vncviewer.c
+@@ -78,9 +78,26 @@ static char* ReadPassword(rfbClient* cli
+ #endif
+ }
+ static rfbBool MallocFrameBuffer(rfbClient* client) {
++ uint64_t allocSize;
+ if(client->frameBuffer)
+ free(client->frameBuffer);
+- client->frameBuffer=malloc(client->width*client->height*client->format.bitsPerPixel/8);
++
++ /* SECURITY: promote 'width' into uint64_t so that the multiplication does not overflow
++ 'width' and 'height' are 16-bit integers per RFB protocol design
++ SIZE_MAX is the maximum value that can fit into size_t
++ */
++ allocSize = (uint64_t)client->width * client->height * client->format.bitsPerPixel/8;
++
++ if (allocSize >= SIZE_MAX) {
++ rfbClientErr("CRITICAL: cannot allocate frameBuffer, requested size is too large\n");
++ return FALSE;
++ }
++
++ client->frameBuffer=malloc( (size_t)allocSize );
++
++ if (client->frameBuffer == NULL)
++ rfbClientErr("CRITICAL: frameBuffer allocation failed, requested size too large or not enough memory?\n");
++
+ return client->frameBuffer?TRUE:FALSE;
+ }
+
only in patch2:
unchanged:
--- libvncserver-0.9.7.orig/debian/patches/07_CVE_2014_6053.patch
+++ libvncserver-0.9.7/debian/patches/07_CVE_2014_6053.patch
@@ -0,0 +1,25 @@
+Description: Check malloc() return value as in CVE-2014-6053
+ 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).
+Origin: Upstream
+Bug-Debian: https://bugs.debian.org/762745
+Applied-Upstream: https://github.com/newsoft/libvncserver/commit/6037a9074d52b1963c97cb28ea1096c7c14cbf28
+Last-Update: 2015-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libvncserver/rfbserver.c
++++ b/libvncserver/rfbserver.c
+@@ -2318,6 +2318,11 @@ rfbProcessClientNormalMessage(rfbClientP
+ msg.cct.length = Swap32IfLE(msg.cct.length);
+
+ str = (char *)malloc(msg.cct.length);
++ if (str == NULL) {
++ rfbLogPerror("rfbProcessClientNormalMessage: not enough memory");
++ rfbCloseClient(cl);
++ return;
++ }
+
+ if ((n = rfbReadExact(cl, str, msg.cct.length)) <= 0) {
+ if (n != 0)
--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com
Reply to: