<div dir="ltr"><a href="https://www.riskbasedsecurity.com/2019/04/vulnerability-fixes-that-make-you-go-hmm/">https://www.riskbasedsecurity.com/2019/04/vulnerability-fixes-that-make-you-go-hmm/</a><br><br>The VulnDB research team processes a large number of vulnerability reports, exploits, and vendor advisories on a daily basis. Each report is scrutinized, classified and added to the VulnDB vulnerability database. They are enriched with important details like affected versions, requirements for exploitation, and sometimes even identifying incorrect fixes.<br><br>The lack of available detail in public reports and disclosures often requires us to dig deeper to create the meaningful intelligence VulnDB is famous for. In some cases, our investigations lead our research team to suspect that something doesn’t quite add up.<br><br>Early March 2019, Kaspersky Labs published information about a stack-based buffer overflow that caught our attention. While these conditions have the potential to allow code execution, the advisory only states denial of service (DoS) as the potential impact. Exploitation also requires user interaction. This was something worth investigating further. The assessment of the affected versions (“UltraVNC before 1.2.2.3”) and the fix (revision 1206) also raised some questions, but first, let’s evaluate the vulnerability itself.<br><br>Looking at the fixing changeset, the affected function ClientConnection:: ShowConnInfo() was changed to address the reported stack-based buffer overflow. This appeared to be triggerable by a specially crafted VNC server, when displaying connection information. (<a href="https://www.riskbasedsecurity.com/wp-content/uploads/2019/04/snprintf.png">IMAGE</a>)<br><br>So far, so good. A sprintf() type function is replaced by _snprintf() with a buffer length limitation. However, looking at a larger part of the function context raised some eyebrows. (<a href="https://www.riskbasedsecurity.com/wp-content/uploads/2019/04/snprintf-buffer-overflow-768x462.png">IMAGE</a>)<br><br>The savvy developer may have already spotted the issue here. The destination buffer is only 2048 bytes is size. Limiting the size when invoking _snprintf() to 20148 does not prevent the buffer overflow, so this apparent typo leaves the application prone to the vulnerability. We downloaded version 1.2.2.3, as “UltraVNC before 1.2.2.3” were reported vulnerable. That’s when we noticed that 1.2.2.3 was released November 11, 2018, about two months before the fix in the repository.<br><br>At this point we have:<br><br>- A stack-based buffer overflow, reported as DoS only<br>- A typo in the fix, which looks insufficient<br>- Ambiguous version information<br><br>When it comes to creating VulnDB entries, we are sometimes driven by what we call VulnDB OCD. We decided to keep digging and figure out what was really going on.<br><br>To trigger the vulnerability, we need to create a VNC server and control one of the parameters used in the _snprintf()call. This could be done via the name associated with the desktop in a ServerInit message (see RFC 6143 – The Remote Framebuffer Protocol). We implemented a Proof-of-Concept using libvncserver and changing the response in the rfbProcessClientInitMessage() function in rfbserver.c. (<a href="https://www.riskbasedsecurity.com/wp-content/uploads/2019/04/vncviewer-pointer-to-next-seh-record-768x359.png">IMAGE</a>)<br><br>When connecting to our VNC server using the vncviewer.exe, the stack-based buffer overflow could be triggered when the user displays the connection information (e.g. via the title context-menu). While this allowed to overflow a wide range of stack memory, exploitation of this vulnerability is mitigated by modern security features such as DEP, SafeSEH, or SEHOP. This is probably the reason why this is initially classified as a denial of service issue. However, at this point, a bypass of these features can’t be ruled out. In particular, ASLR (Address Space Layout Randomization) is not enabled in the application, which aids when using return-oriented programming (ROP) techniques to bypass e.g. DEP.<br><br>(As a side-note: a crash in a client application requiring user interaction, e.g. connecting to a specially crafted VNC server, would not be classified as a vulnerability, but rather a stability issue).<br><br>On March 14, 2019, a new version (1.2.2.4) was released, which included the insufficient fix. We tested this version against our VNC server and, not surprisingly, could still reproduce the stack-based buffer overflow. We then contacted the vendor to inform them the incomplete fix and quickly received a response that the issue was corrected with revision 1216 with the vendor silently updating 1.2.2.4 as of March 19, 2019.<br><br>The result of our brief excursion:<br><br>- The denial of service non-issue turned out to be potentially exploitable for arbitrary code execution.<br>- Version 1.2.2.3 was vulnerable, even though the advisory suggested otherwise.<br>- Early downloads of 1.2.2.4 were affected due to a typo in the initial fix.<br>- Only version 1.2.2.4 downloaded after March 19, 2019 addresses the vulnerability with a silent fix.<br><br>Hmmm indeed.<br><br>Learn more about how VulnDB and our research team can equip your security team with better data.<br><br><br></div>