[BreachExchange] Vulnerability fixes that make you go hmm…

[Destry Winant]

https://www.riskbasedsecurity.com/2019/04/vulnerability-fixes-that-make-you-go-hmm/

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.

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.

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.

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. (IMAGE
<https://www.riskbasedsecurity.com/wp-content/uploads/2019/04/snprintf.png>)

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. (IMAGE
<https://www.riskbasedsecurity.com/wp-content/uploads/2019/04/snprintf-buffer-overflow-768x462.png>
)

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.

At this point we have:

- A stack-based buffer overflow, reported as DoS only
- A typo in the fix, which looks insufficient
- Ambiguous version information

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.

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. (IMAGE
<https://www.riskbasedsecurity.com/wp-content/uploads/2019/04/vncviewer-pointer-to-next-seh-record-768x359.png>
)

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.

(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).

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.

The result of our brief excursion:

- The denial of service non-issue turned out to be potentially exploitable
for arbitrary code execution.
- Version 1.2.2.3 was vulnerable, even though the advisory suggested
otherwise.
- Early downloads of 1.2.2.4 were affected due to a typo in the initial fix.
- Only version 1.2.2.4 downloaded after March 19, 2019 addresses the
vulnerability with a silent fix.

Hmmm indeed.

Learn more about how VulnDB and our research team can equip your security
team with better data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20190502/af754bc6/attachment.html>