CVE-2019-15695 (published 2019-12-26T16:15Z)

TigerVNC version prior to 1.10.1 is vulnerable to stack buffer overflow, which could be triggered from CMsgReader::readSetCursor. This vulnerability occurs due to insufficient sanitization of PixelFormat. Since remote attacker can choose offset from start of the buffer to start writing his values, exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.

Severity: MEDIUM
CVSS v2 base score: 6.5 (AV:N/AC:L/Au:S/C:P/I:P/A:P)
CVSS v3 base score: 7.2, HIGH (CVSS:3.1/AV:N/AC:L/PR:H/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: 
            
            
             
			 
         
         
cwe_id: CWE-754
cwe_name: Improper Check for Unusual or Exceptional Conditions
description: The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
extended_description: 
            The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability.
            Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.
         
         

Fix information:
repo_url: https://github.com/CendioOssman/tigervnc
commit_details: repo_url: https://github.com/CendioOssman/tigervnc
author: Pierre Ossman
author_date: 2019-10-02 16:06:08+02:00
msg: Handle pixel formats with odd shift values

Our fast paths assume that each channel fits in to a separate byte.
That means the shift needs to be a multiple of 8. Start actually
checking this so that a client cannot trip us up and possibly cause
incorrect code exection.

Issue found by Pavel Cheremushkin from Kaspersky Lab.
repository: repo_url: https://github.com/CendioOssman/tigervnc
repo_name: CendioOssman/tigervnc
repo_language: C++
owner: CendioOssman
file_changes: filename: PixelFormat.cxx
change_type: ModificationType.MODIFY
diff: @@ -206,6 +206,12 @@ bool PixelFormat::is888(void) const
     return false;
   if (blueMax != 255)
     return false;
+  if ((redShift & 0x7) != 0)
+    return false;
+  if ((greenShift & 0x7) != 0)
+    return false;
+  if ((blueShift & 0x7) != 0)
+    return false;
 
   return true;
 }

programming_language: C++
filename: pixelformat.cxx
change_type: ModificationType.MODIFY
diff: @@ -170,6 +170,12 @@ void is888Tests()
 
     do888Test(false, 8, 8, false, false, 0, 0, 0, 0, 0, 0);
 
+    /* Odd shifts */
+
+    do888Test(false, 32, 24, false, true, 255, 255, 255, 0, 8, 18);
+    do888Test(false, 32, 24, false, true, 255, 255, 255, 0, 11, 24);
+    do888Test(false, 32, 24, false, true, 255, 255, 255, 4, 16, 24);
+
     printf("\n");
 }
 

programming_language: C