Bug 897031 (CVE-2014-6051) - VUL-0: libvncserver / other vnc implementation: various issues
Summary: VUL-0: libvncserver / other vnc implementation: various issues
Status: RESOLVED FIXED
Alias: CVE-2014-6051
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-17 06:52 UTC by Marcus Meissner
Modified: 2016-04-27 19:30 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2014-09-17 06:52:34 UTC
semi embargoed via oCert / distros

Hello everybody,

the following public commits concerning some libvncserver issues have been
reported to us by the reporter. CVE numbers have already been requested by
the reporter and assigned for each issue.

A lot of Open Source products are probably affected, including x11vnc,
KRFB/KRDC and VirtualBox, however it must be noted that all issues are
post-authentication.

Considering that everything is public I merely wanted to forward privately
the information we received, in the meantime I'll figure out what the
reporter wants to do in terms of advisory and probably suggest that he takes
this on oss-security.

Here are the individual issues (and later some further comments):

---------------------------------------------------------------------------------------

https://github.com/newsoft/libvncserver/commit/045a044e8ae79db9244593fbce154cdf6e843273
CVE-2014-6051

A malicious VNC server could advertise a very large screen size (by RFB
protocol, width and height are 16-bit integers), resulting in an integer
overflow during malloc() on client-side. Heap corruption, and possibly remote
code execution on client-side could ensue.

---------------------------------------------------------------------------------------

https://github.com/newsoft/libvncserver/commit/85a778c0e45e87e35ee7199f1f25020648e8b812
CVE-2014-6052

malloc() return value was not checked on client-side during
framebuffer setup. A malicious VNC server that advertises a large
enough screen size to make malloc() fail could basically map the
framebuffer at address 0, and write anything-anywhere in client
process memory using selective FramebufferUpdate messages. This could
certainly turn into remote code execution on client-side.
---------------------------------------------------------------------------------------

https://github.com/newsoft/libvncserver/commit/6037a9074d52b1963c97cb28ea1096c7c14cbf28

A malicious client could advertise a very large ClientCutText message size
(by RFB protocol, size is encoded on a 32-bit integer). malloc() is likely to
fail in that case; as malloc() return value is not checked, this will most
likely result in a server crash.

Note: this issue also affects RealVNC
http://www.iss.net/security_center/reference/vuln/VNC_Client_Cut_Text_DoS.htm
http://packetstormsecurity.com/files/89160/RealVNC-VNC-Server-Free-Edition-4.1.3-Denial-Of-Service.html
Sending a ClientCutText Message with a length of 0xFFFFFFFF crashes the server

MITRE comments:
Use CVE-2014-6053 for this libvncserver issue, which might also be
interpreted as the server attempting to do normal processing of
ClientCutText message sizes up to 2**32-1, even though clients that
actually implement desktop sharing on a typical OS would not have more
than 2**31-1 bytes of data available to send. (Even if this were not
the case, CVE-2014-6053 could still be used for the mishandling of
attempts at processing large values.)

The previously reported RealVNC issue is CVE-2010-5304.

---------------------------------------------------------------------------------------

https://github.com/newsoft/libvncserver/commit/05a9bd41a8ec0a9d580a8f420f41718bdd235446
CVE-2014-6054.

A malicious client could set the scaling factor to 0, which will
result in a server crash (division by zero).

---------------------------------------------------------------------------------------

https://github.com/newsoft/libvncserver/commit/06ccdf016154fde8eccb5355613ba04c59127b2e


The non-standard file transfer messages (UltraVNC feature) will
blindly strcpy() client-provided file and directory names into a
stack-based buffer of size MAX_PATH, resulting in multiple stack-based
buffer overflows on server-side.

https://github.com/newsoft/libvncserver/commit/f528072216dec01cee7ca35d94e171a3b909e677

Client-supplied FileTime attribute is copied into a stack-based buffer
of size 64 during rfbFileTransferOffer message parsing, resulting in a
stack-based buffer overflow on server-side.

MITRE comments:
Use CVE-2014-6055 for all of the stack-based buffer overflows (we realize
that the last one is in unrelated code).

---------------------------------------------------------------------------------------

Some further remarks from reporter:

* VNC server can be set to "security:none", which basically means no auth.
This makes sense if VNC is connecting you to a login screen afterwards
(e.g. x11vnc). In that configuration, all server-side bugs could be
leveraged anonymously.

* Using VNC over an insecure network. Ok, this is not very security-wise in
the first place. But if you are in a man-in-the-middle position, you can
actually execute code on client-side or server-side, depending on the bug
you trigger.

* Connecting to an untrusted VNC server and getting owned. For instance, if
you connect to a VirtualBox client running some piece of malware which sets
the screen resolution to 8192 x 8192 x 32bpp, then malloc() will fail and
return NULL on client-side, basically mapping the framebuffer at address 0.
Thereafter the VM screen content can overwrite selected parts of the client
memory through partial updates, probably leading to client-side code
execution.

* Some "Cloud" providers might actually provide their clients with VNC
access to hosted instances. Being able to exploit the VNC server would
actually mean evasion from the virtualization boundary (this would work for
VirtualBox, at least. I am currently testing other virtualization software).

* Last but not least, some people are actually providing support to
end-users through VNC. Not sure if the end-user expects support personnel
to be able to run shellcode in the background.

-- 
Andrea Barisani |                Founder & Project Coordinator
          oCERT | OSS Computer Security Incident Response Team

<lcars@ocert.org>                         http://www.ocert.org
 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
        "Pluralitas non est ponenda sine necessitate"
Comment 1 Marcus Meissner 2014-09-17 06:53:22 UTC
will have to do a matrix of affectedness :/
Comment 2 Swamp Workflow Management 2014-09-17 22:00:20 UTC
bugbot adjusting priority
Comment 3 Marcus Meissner 2014-09-24 07:52:23 UTC
published to oss-sec

From: Nicolas RUFF <nicolas.ruff@gmail.com>
Date: Tue, 23 Sep 2014 23:47:05 +0200

Hello list,

I am currently reviewing libVNCserver for potential security issues.

Project home is: https://github.com/LibVNC/libvncserver

Here are my findings so far. Found bugs are either client- or server-side
(libVNCserver provides both). All bugs require authentication. However they
still pose a significant issue in the following scenarios:
* VNC server is running in password-less mode because authentication is
required afterwards (e.g. X11 login screen).
* Attacker is located in a man-in-the-middle position.
* Attacker has legitimate access to the VNC server but possibly not to the
host server (e.g. virtual machine, remote assistance to a customer).

Fixes are being committed - a few of them are still pending in the pull
request.

CVE-2014-6051 Integer overflow in MallocFrameBuffer() on client side.

A malicious VNC server could advertise a very large screen size (by RFB
protocol, width and height are 16-bit integers), resulting in an integer
overflow during malloc() on client-side. Heap corruption, and possibly
remote code execution on client-side could ensue.

CVE-2014-6052 Lack of malloc() return value checking on client side.

malloc() return value was not checked on client-side during framebuffer
setup. A malicious VNC server that advertises a large enough screen size to
make malloc() fail could basically map the framebuffer at address 0, and
write anything-anywhere in client process memory using selective
FramebufferUpdate messages. This could certainly turn into remote code
execution on client-side.

CVE-2014-6053 Server crash on a very large ClientCutText message.

A malicious client could advertise a very large ClientCutText message size
(by RFB protocol, size is encoded on a 32-bit integer). malloc() is likely
to fail in that case; as malloc() return value is not checked, this will
most likely result in a server crash.

Note: this issue also affects RealVNC as per CVE-2010-5304.
http://www.iss.net/security_center/reference/vuln/VNC_Client_Cut_Text_DoS.htm
http://packetstormsecurity.com/files/89160/RealVNC-VNC-Server-Free-Edition-4.1.3-Denial-Of-Service.html

CVE-2014-6054 Server crash when scaling factor is set to zero.

A malicious client could set the scaling factor to 0, which will result in
a server crash (division by zero).

CVE-2014-6055 Multiple stack overflows in File Transfer feature.

1/ The non-standard file transfer messages (UltraVNC feature) will blindly
strcpy() client-provided file and directory names into a stack-based buffer
of size MAX_PATH, resulting in multiple stack-based buffer overflows on
server-side.

2/ Client-supplied FileTime attribute is copied into a stack-based
buffer of size 64 during rfbFileTransferOffer message parsing, resulting in
a stack-based buffer overflow on server-side.

Regards,
- Nicolas RUFF
Comment 4 Marcus Meissner 2014-09-25 12:19:54 UTC
another summary from oCert

From: Andrea Barisani <lcars@ocert.org>
Date: Thu, 25 Sep 2014 13:59:51 +0200
Subject: [oss-security] [oCERT-2014-007] libvncserver multiple issues

#2014-007 libvncserver multiple issues

Description:

Virtual Network Computing (VNC) is a graphical sharing system based on the
Remote Frame Buffer (RFB) protocol.

The LibVNCServer project, an open source library for implementing VNC
compliant communication, suffers from a number of bugs that can be potentially
exploited with security impact.

Various implementation issues resulting in remote code execution and/or DoS
conditions on both the VNC server and client side have been discovered.

 1. A malicious VNC server can trigger incorrect memory management
    handling by advertising a large screen size parameter to the VNC
    client. This would result in multiple memory corruptions and could
    allow remote code execution on the VNC client.

 2. A malicious VNC client can trigger multiple DoS conditions on the VNC
    server by advertising a large screen size, ClientCutText message
    length and/or a zero scaling factor parameter.

 3. A malicious VNC client can trigger multiple stack-based buffer
    overflows by passing a long file and directory names and/or attributes
    (FileTime) when using the file transfer message feature.

It should be noted that every described issue represents a post-authentication
bug, therefore the server side conditions can be anonymously leveraged only if
the VNC server is configured to allow unauthenticated sessions.

Affected version:

LibVNCServer <= 0.9.9

Fixed version:

LibVNCServer, N/A

Credit: vulnerability report received from Nicolas Ruff
        of Google Security Team <nruff AT google.com>.

CVE: CVE-2014-6051 (1), CVE-2014-6052 (1), CVE-2014-6053 (2),
     CVE-2014-6054 (2), CVE-2014-6055 (3)

Timeline:

2014-09-05: vulnerability report received
2014-09-16: contacted affected vendors
2014-09-22: contacted additional affected vendors
2014-09-25: advisory release

References:
(1) https://github.com/newsoft/libvncserver/commit/045a044e8ae79db9244593fbce154cdf6e843273
(2) https://github.com/newsoft/libvncserver/commit/6037a9074d52b1963c97cb28ea1096c7c14cbf28
(2) https://github.com/newsoft/libvncserver/commit/05a9bd41a8ec0a9d580a8f420f41718bdd235446
(3) https://github.com/newsoft/libvncserver/commit/06ccdf016154fde8eccb5355613ba04c59127b2e
(3) https://github.com/newsoft/libvncserver/commit/f528072216dec01cee7ca35d94e171a3b909e677

Permalink:
http://www.ocert.org/advisories/ocert-2014-007.html
Comment 6 Sebastian Krahmer 2015-11-24 15:02:51 UTC
released
Comment 7 Swamp Workflow Management 2015-11-24 18:14:27 UTC
SUSE-SU-2015:2088-1: An update that fixes 5 vulnerabilities is now available.

Category: security (moderate)
Bug References: 854151,897031
CVE References: CVE-2014-6051,CVE-2014-6052,CVE-2014-6053,CVE-2014-6054,CVE-2014-6055
Sources used:
SUSE Linux Enterprise Software Development Kit 12 (src):    LibVNCServer-0.9.9-15.1
SUSE Linux Enterprise Server 12 (src):    LibVNCServer-0.9.9-15.1
SUSE Linux Enterprise Desktop 12 (src):    LibVNCServer-0.9.9-15.1
Comment 8 Swamp Workflow Management 2015-11-26 14:11:47 UTC
SUSE-SU-2015:2110-1: An update that fixes 5 vulnerabilities is now available.

Category: security (moderate)
Bug References: 897031
CVE References: CVE-2014-6051,CVE-2014-6052,CVE-2014-6053,CVE-2014-6054,CVE-2014-6055
Sources used:
SUSE Linux Enterprise Software Development Kit 11-SP4 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Software Development Kit 11-SP3 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Server for VMWare 11-SP3 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Server 11-SP4 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Server 11-SP3 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Desktop 11-SP4 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Desktop 11-SP3 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src):    LibVNCServer-0.9.1-156.1
SUSE Linux Enterprise Debuginfo 11-SP3 (src):    LibVNCServer-0.9.1-156.1
Comment 9 Swamp Workflow Management 2015-12-04 14:13:27 UTC
openSUSE-SU-2015:2207-1: An update that fixes 5 vulnerabilities is now available.

Category: security (moderate)
Bug References: 854151,897031
CVE References: CVE-2014-6051,CVE-2014-6052,CVE-2014-6053,CVE-2014-6054,CVE-2014-6055
Sources used:
openSUSE Leap 42.1 (src):    LibVNCServer-0.9.9-13.1
Comment 10 Swamp Workflow Management 2015-12-30 16:12:52 UTC
SUSE-SU-2015:2088-2: An update that fixes 5 vulnerabilities is now available.

Category: security (moderate)
Bug References: 854151,897031
CVE References: CVE-2014-6051,CVE-2014-6052,CVE-2014-6053,CVE-2014-6054,CVE-2014-6055
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP1 (src):    LibVNCServer-0.9.9-16.1
SUSE Linux Enterprise Server 12-SP1 (src):    LibVNCServer-0.9.9-16.1