CVE-2019-15683 (published 2019-10-29T19:15Z)

TurboVNC server code contains stack buffer overflow vulnerability in commit prior to cea98166008301e614e0d36776bf9435a536136e. This could possibly result into remote code execution, since stack frame is not protected with stack canary. This attack appear to be exploitable via network connectivity. To exploit this vulnerability authorization on server is required. These issues have been fixed in commit cea98166008301e614e0d36776bf9435a536136e.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-787
cwe_name: Out-of-bounds Write
description: The product writes data past the end, or before the beginning, of the intended buffer.
extended_description: 
            
            
             
			 
         
         

Fix information:
repo_url: https://github.com/TurboVNC/turbovnc
commit_details: repo_url: https://github.com/TurboVNC/turbovnc
author: DRC
author_date: 2019-08-23 09:54:21-05:00
msg: Server: Fix two issues identified by ASan

1. If the TLSPlain and X509Plain security types were both disabled, then
   rfbOptPamAuth() would overflow the name field in the secTypes
   structure when testing the "none" security type, since the name of
   that security type has less than five characters.  This issue was
   innocuous, since the overflow was fully contained within the secTypes
   structure, but the ASan error caused Xvnc to abort, which made it
   difficult to detect other errors.

2. If an ill-behaved RFB client sent the TurboVNC Server a fence
   message with more than 64 bytes, then the TurboVNC Server would
   try to read that message and subsequently overflow the stack before
   it detected that the payload was too large.  This could never have
   occurred with any of the VNC viewers that currently support the RFB
   flow control extensions (TigerVNC and TurboVNC, namely.)  This issue
   was also innocuous, since the stack overflow affected two variables
   (newScreens and errMsg) that were never accessed before the function
   returned.
repository: repo_url: https://github.com/TurboVNC/turbovnc
repo_name: TurboVNC/turbovnc
description: Main TurboVNC repository
repo_language: C
owner: TurboVNC
file_changes: filename: auth.c
change_type: ModificationType.MODIFY
diff: @@ -393,7 +393,7 @@ Bool rfbOptPamAuth(void)
 
   for (s = secTypes; s->name != NULL; s++) {
     if ((!strcmp(s->name, "unixlogin") ||
-         !strcmp(&s->name[strlen(s->name) - 5], "plain")) && s->enabled)
+         strstr(s->name, "plain")) && s->enabled)
       return TRUE;
   }
 

programming_language: C
filename: rfbserver.c
change_type: ModificationType.MODIFY
diff: @@ -1314,13 +1314,15 @@ static void rfbProcessClientNormalMessage(rfbClientPtr cl)
 
       flags = Swap32IfLE(msg.f.flags);
 
-      READ(data, msg.f.length)
-
-      if (msg.f.length > sizeof(data))
+      if (msg.f.length > sizeof(data)) {
         rfbLog("Ignoring fence.  Payload of %d bytes is too large.\n",
                msg.f.length);
-      else
+        SKIP(msg.f.length)
+      } else {
+        READ(data, msg.f.length)
         HandleFence(cl, flags, msg.f.length, data);
+      }
+
       return;
     }
 

programming_language: C