A user reported a "denial of service via a crafted frame buffer update packet" issue with our latest VNC Viewer.
RealVNC's internal investigation revealed this to be an issue in the Zlib decoding; which can cause the Viewer process to "hang". Note this is not a crash - the Viewer process gets caught in a tight loop and never recovers. This can be triggered via a crafted frame buffer update packet, causing the Zlib stream to close unexpectedly.
Although the original report mentions "denial of service" - only the Viewer process associated with the connection to the proof of concept Server is affected. Any other concurrent connections are not affected and their usage can continue even after this connection process has been terminated.
This issue affects the Viewer-side only, this does not affect VNC Server or any VNC Connect web service.
This issue has been given an internal CVSS score of 2.6:
Note, the Availability Impact (A) above was given a score of "Partial", due to the memory/CPU resources being consumed on the Viewer machine end whilst the process is hung. Note that no memory leak occurs, the resources are freed once the hung process is terminated and the usage is constant.
There are a number of prerequisites for this to be a real-world issue:
- As this is a Viewer-side issue, social engineering is required to trick a user into connecting to the fake server
The public proof of concept server requires the user to accept an "Unencrypted Connection" warning
- 07 September 2021 Initial contact received
- 15 September 2021 Initial RealVNC response to reporter requesting information
- 16 September 2021 Details and proof of concept script received
- 17 September 2021 RealVNC response to reporter
- 17 September 2021 CVE created by reporter
- 20 September 2021 Connection hang fix identified
- 20 September 2021 RealVNC response sent to MITRE